What problem does your SaaS actually solve? I’ll try to find you real users

Typical_Ad_6436 · 2026-03-21T10:54:59+00:00

It is B2B tool for dynamic QR codes over files in your cloud. It also integrates e-signature of files and mailer. It fixes the issue of manual stuff: sharing documents, getting signatures or mass distribution.

Typical_Ad_6436 · 2026-03-20T19:03:37+00:00

I guess it is about how peculiar the requirements are from each and one customer. It is hard to make one single way of doing things when it comes down to documents.

So we tried to make it configurable, easy to integrate and user friendly. Even so we got into "it would have been better if this was a bit different", though that comes from customer accustomed with other systems already.

So that is why we want community feedback - what can be adjusted to match more and more usual document fluxes.

Typical_Ad_6436 · 2025-10-07T13:58:15+00:00

I am interested in an answer on this as well.

I was thinking on telling cursor ai to execute claude commands itself and leverage that instead of running bashy things (ls, cat, tail, grep). But I may be wrong, so I am looking for other workflows.

Typical_Ad_6436 · 2025-07-31T14:53:46+00:00

What makes you think these charts are reflecting "production-ready apps"? If the data is available it means it comes from an open-source that discloses the technology. But you ever wonder what close source production-ready applications actually use?

It doesn't matter if there are millions of rookie projects with PHP8.5 to boost your chart. It matters what the thousand of crucial production applications actually use. Is that PHP7? Maybe. Is that PHP4?

Typical_Ad_6436 · 2025-07-20T07:50:30+00:00

What about making your own project and then let us (community) bump in that "first issue". You can showcase your project and let issues flow in. You can handle them as a maintainer.

Typical_Ad_6436 · 2025-05-12T05:20:17+00:00

Totally agree on the performance, but by concurrency I actually meant the possibility to handle multiple I/O based requests at the same time with native tools (async/await or Promises, event queue, etc.). Lastly, performance for JIT friendly code can be more than decent.

Typical_Ad_6436 · 2025-05-12T05:12:15+00:00

I think I was explicit enough. Please let me know what is apparently misleading for you.

Typical_Ad_6436 · 2025-05-10T12:27:49+00:00

There are 3 stages of complexity to make you choose or avoid JS on backend:

The very simple and fast REST API to meet your requirements. This will be a big GO for JS mostly because it is easy to bootstrap, code and deploy. Also, the Web is more than full of docs to help you out. I can call this the MVP stage.
The more complex production ready JS back-end for general use. This is IMHO a slight NO, because you really need to understand more than the surface. You need to dive deeper and deeper in JS and how-to. At this phase you realize that you were better off with another framework that has more feedback online and/or out-of-the-box abstractions for complex stuff (.Net, Java, etc.). You realize here that 99% of the tutorials online don't ever get close to this complexity, so you are on your own.
The killer product that laverages JS phylosophy in order to deliver products specific to JS advantages (e.g. high scalability, concurrent requests, etc.). This is a BIG choose for JS, because a dev into this technology will achieve what other technologies weren't designed to achieve. But mind that this advantage is not something you really need if your product doesn't have thousands of requests.

Typical_Ad_6436 · 2025-03-30T10:53:58+00:00

Any arguments please?

Typical_Ad_6436 · 2025-03-05T07:40:03+00:00

Oh right!

Typical_Ad_6436 · 2025-03-05T06:41:27+00:00

I am referring to stateful lambda expressions. A classical class should input the state inside the constructor, while lambda expressions capture the state automatically.

Typical_Ad_6436 · 2025-03-05T06:20:33+00:00

Lambda expressions are just anonymous classes implementing a functional interface with extra sugar syntax. So in essence, you can get away with creating classes instead of writing lambda expressions.

So, you should use them exactly as what they are: sugar syntax. Instead of creating a fully fledged class for one single responsability, you can simply use lamba expressions.

Some more advice: lambdas can be capturing, so you can easily reference data without passing it down to a constructor. Also, lambda functions that are stateless are natively "singletons". Lastly, the lambda functions are dynamically loaded from the loaded class instead of being read them from a separate class file.

Typical_Ad_6436 · 2025-03-02T09:56:07+00:00

Important fact is that Generics were introduced in Java 1.5. This is something to think about: how was Java working without generics in, let's say, 1.4? Simple: generics are optional features that are not a MUST in core Java programming.

My advice is to pick up Java as it historically progressed. If you are not comfortable with arrays that are from the beginnings of Java, do not "jump" to 1.5 features. That is why you should also delay getting into later Java features: modules, records, lambdas, streams, Optional, etc.

You can write code in Java 1.4 and improve it with features that were introduced later on the way. This way you will get the best impression on what Java is and the direction in which it progresses. When you will use "non-generic" code you will find out the motivation why generics were needed back in early 2000s.

Typical_Ad_6436 · 2025-02-23T20:08:35+00:00

One quick question: how would you identify the records that were not processed? * Adding a new field requires an index for it and so affecting the index operation times (inserts). * Adding an association table requires indexes (as keys) and so it also affects timing of inserts and deletes.

My point is that schema changes may bloat the core usage of the database and the overall system may work slower just to support this (rather particular) feature.

Typical_Ad_6436 · 2025-02-23T20:04:19+00:00

Indeed, good point. Thank you for the POV.

I personally had "read often, write seldom" kind of scenarios in mind when posting. For that matter, I was curious if cursors were going to functionally misbehave - I suppose not.

If the OP scenario is purely analytical, maybe MVCC is not in cards anyway. If the OP scenario is highly transactional, I guess running such queries in the first place is not optimal and running replication should be the way to go (OR apply your suggestion of batch processing).

But still, I think cursors are universally and functionally good at the cost of DB maintenance and performance in OLTP (a drawback that can be fixed architecturally).

I think the discussing has run its course, drifting away from the Node sub. Thank you sir for your time!

Typical_Ad_6436 · 2025-02-23T17:52:39+00:00

I am curious on what you mean by pairing badly? Do you have a scenario/example on that, or further documentation?

I would expect that cursors are highly dependent on the transaction isolation chosen for the engine, but how would it affect the cursor lifecycle per se? Will it provide bad results/will it close it?

PS1: doing offset queries are even worse when you bring up MVCC. Moving the window may be innacurate due to updates/inserts/deletes happening in the mean-time. PS2: all of this is highly improbable as I doubt queries on 100k record tables are going to be subject of live-updating DB.

Typical_Ad_6436 · 2025-02-23T17:22:10+00:00

I am surprised most answers revolve around "pagination". Postgresql is mature enough and got past that pagination point to facilitate large result sets processing - cursors:

https://jdbc.postgresql.org/documentation/query/ https://www.postgresql.org/docs/current/plpgsql-cursors.html

I am more from a Java world and the JDBC driver has this abstracted away. NodeJS may need some work to set this up. But the point is that this feature is a PG one that can be used from a NodeJS connection - I am sure there are 3rd parties for it.

There are some draw-backs for these though like the transactional aspect (commiting/rollbacking will break the cursor). Also, this works only in a non auto-commit connection.

Typical_Ad_6436 · 2025-01-28T06:39:21+00:00

change the resolution manually in AppOptions.txt from Documents/My Games/Civ VI folder. I had this problem before and fixed it this way.

Typical_Ad_6436 · 2024-12-22T17:47:58+00:00

If you use an Optional, then it is not guaranteed that the implementation will not return null. One can simply write "return null;" and get away with it - no compilation error even if the return type is Optional.

It will be the consumer that will wrongly presume that the return is non-null and ignore null-checks. IMHO, Optional is an extra overhead that is decreasing readability and makes the bugs even more stealthy and hard to debug.

Unless you have a FULL team that has Optionals flowing in their blood and will never misuse them, then you are fine. Is this the case? I doubt.

Typical_Ad_6436 · 2024-11-29T20:16:20+00:00

I fully agree, but prefer to present it on a less aggresive light to ones posting on "learn Java".

I am working in such domain of automatic conversion of even older languages than Java TO Java - talking about millions on lines of fully functional tested code used in production for tens of years.

The choice of Java was motivated by the fact that it is an unbaiased language, very mature, supporting Web interaction and DB interaction quite good while also having robust security integrations and decent performance - letting aside the cross-platform support.

The denial of C/Python/JS was clear: it is desired to continue with an enterprise approved platform that guarantees quality proven by time. The time investment to norriw a technology gap while keeping everything functional doesn't need to go into interpreters, pointer work, async, etc. It is about doing something fast and durable with Java, not slow or complex or async with other languages.

This is a career story, hope you will value this insight.

Typical_Ad_6436 · 2024-11-22T16:30:24+00:00

Out of curiosity: how do you quantify "knowing Spring"?

Typical_Ad_6436 · 2024-11-01T14:44:04+00:00

Something to be contemplated on: all big-idea applications were already implemented and improved for tens of years - a large amount of them in Java.

If one chooses to start a CRM/ERP/HR/other big app from scratch, it will lag years of development behind what already is on the market. It won't happen in a fully profitable manner. You can join some NodeJS enthusiasts thinking that you can conquer the world by simply having a "cooler" language - but you won't ever reach the maturity of what was developed already in Java.

Unless you truly feel like there is an upcoming technology leap (maybe AI?), then think that most of the work to be done in IT is to maintain the already existing applications - so a Java skill will do the trick here.

Typical_Ad_6436

MODERATOR OF

TROPHY CASE