Can someone explain me how prisma ORM works? I just finished a course with nextjs that uses prisma. Prisma basiclly performed all crud operations on mongodb for example. I saw no usage or need for cloud providers (aws). No backend separation. Like literally all of it was done in fucking nextjs. Very efficiently coded but still how is this good? Please explain why not built a separate backend. Why do it like this

Nextjs has a backend and prisma probably runs there. It's SSR so some parts are run on the server in "server components". And prisma does a bunch of magic to generate db queries, but the queries tend to be quite inefficient

@ScriptCoded why are queries inefficient? I'm kinda confused how is this any good?

Nextjs is basically a full stack framework. Both backend and frontend.

Now the "backend" part is cluttered with the frontend part. So how is this good please?

@ScriptCoded How is coupling backend + frontend as a single nextjs app a good idea? What the fuck is this?

What if you have to create new replica sets of a backend because of high load pressure? What about load balancers?? WTF IS THIS

WHY DID NEXTJS THINK THIS IS A GOOD IDEA AND WHY DO SO MANY DEVS LOVE THIS IDEA?

It's JavaScript.

What do you expect? Wisdom and good design?

NextJS mixes frontend and backend.

Server Side Rendering included.

Same way e.g. many javascript frameworks completely destroyed the barrier between html, css, template generation.

Not for the good in my opinion.

@IntrusionCM please how is this a good idea? This is insane. I hate javascript since the dawn of its existence. But why is this approach being glorified? I feel like if i take this approach and build projects this way i degraded my dev skills drastically. No more aws. No more devops. Yes thats much easier but at what cost?

@b2plane

Well, it all has its benefits. If it wasn't JS, I probably would be less against it.

That's my main problem.

JS and scaling is a walk on a razor's edge.

If the team knows what they're doing, how to scale, how to keep everything secure and up-to-date...

Then SSR and projects like Prism which move frontend and backend together could reduce latency, could make things easier and could provide benefits like tight Integration.

But by all means: I've had in 10 years plus only a handful of teams who managed to deliver that.

At worst we had an Angular SSR which the devs managed to fill up with so many hacks that the whole SSR generation basically became synchronous - one connection top to the NodeJS process, nothing could be done asynchronous. Unplugging that Sodom and Gomorrah was one of my most blessed days.

@b2plane monoliths are faster to create, and easier to maintain. They should be the defacto choice for prototyping and MVPs.

They don't scale horizontally, but if that's a real problem your app is having, you're having very good problems.

Engineering wise, separate components are a better design, but for business sense, it's all about rapid iterations. Remember, most apps don't get 10 customers, let alone enough to need 20 API replicas running behind a load balancer.

@lungdart read my new rant

It’s just an ORM. It makes queries for you.
The end.
You still have a backend, even if you don’t see it.

@lungdart depends, but yrs if the team it not to big and there is no extreme performance needed a monolith is easier to build and maintain.

But to be honest, even a monolith has separate parts, its just not thought as parts :)

The DB is usually external and you most likely have not built your own webserver.

If you run multiple instances you are most likely using a load balancer

Going microservices is quite a lot similar just going much further and should only be done if you have very good reasons for it since it adds quite a lot of other complexity.

Prisma has these little engines built in Rust, but not really optimizing your queries for you... So, this did age well?