Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Prisma – ORM for Node.js and TypeScript

prisma.io

Post reply on HN
Print view View original

231–240 of 260 posts

Re: Prisma – ORM for Node.js and TypeScript

#231

Post by spion »

sonthonax wrote: post #94
spion wrote: post #85

Earlier quoted context omitted.

What are you comparing it to? What is the better alternative?

SQL isn't the only RDMS language, but it is the one with 50 years of incumbency. Postgres before it was called 'PostgreSQL', used something called QUEL, which is quite a bit cleaner. There is also Microsoft's LINQ. A typical programming language can express all that SQL can. In a way, an ORM is a cross-compiler from your programming language to SQL.

LINQ is pretty much a clone of SQL. Its nice, I agree, but do you think its materially different?

SQL could benefit from being language-integrated, yes. Very few languages can model relational algebra types though, if thats a thing you care about (it certainly is for me).

Re: Prisma – ORM for Node.js and TypeScript

#232

Post by infensus »

matheusmoreira wrote: post #218
ragnese wrote: post #213

Earlier quoted context omitted.

Node-the-software-project is a feat of engineering. But the API, the client language, the ecosystem, and even the idea are bad, IMO. Bad API example: Tell me how to deal with time zones in Node without pulling in a big third party library. Answer: You can't. So, a "scalable" backend platform can't handle datetimes from different time zones? Neat! "Well, that's JavaScript's fault" you say. Node certainly has (a few) A…

> Not to mention that it's single-threaded, so the answer to scaling up better is to just run more instances. Yeah, this sucks. It's impossible to do any actual processing in javascript since functions that don't return immediately will clog the event loop. Why can't we have javascript code that runs asynchronously and reports completion and results as events? Even browsers seem to have this now. I tracked issue #213…

Node has worker threads, which are basically the equivalent of Web Workers from browsers, with similar message based API

Re: Prisma – ORM for Node.js and TypeScript

#233

Post by matheusmoreira »

infensus wrote: post #232
matheusmoreira wrote: post #218

Earlier quoted context omitted.

> Not to mention that it's single-threaded, so the answer to scaling up better is to just run more instances. Yeah, this sucks. It's impossible to do any actual processing in javascript since functions that don't return immediately will clog the event loop. Why can't we have javascript code that runs asynchronously and reports completion and results as events? Even browsers seem to have this now. I tracked issue #213…

Node has worker threads, which are basically the equivalent of Web Workers from browsers, with similar message based API

Wow really? Since when/what version? I have to see it. How did they solve the serialization issue? If I remember correctly that was necessary to pass objects between threads.

Re: Prisma – ORM for Node.js and TypeScript

#234

Post by infensus »

matheusmoreira wrote: post #233
infensus wrote: post #232

Earlier quoted context omitted.

Node has worker threads, which are basically the equivalent of Web Workers from browsers, with similar message based API

Wow really? Since when/what version? I have to see it. How did they solve the serialization issue? If I remember correctly that was necessary to pass objects between threads.

I think they became stable in v12. I'm actually not sure about the internal implementation, but from user's point of view you can pass almost [1] any value via a message and you will get a copy on the other side. You can even share memory between threads with SharedArrayBuffer.

[1] https://nodejs.org/api/worker_threads.html#worker_threads_po...

Re: Prisma – ORM for Node.js and TypeScript

#235

Post by narrator »

matheusmoreira wrote: post #212
slashdev wrote: post #188

I don't like ORMs, but Prisma is one of the better ones. It avoids a lot of shortcomings of popular ORMs. I hope they find a way to make it work as a company. I've been following them over the years from the beginning of their journey through various pivots. To use an ORM effectively you must learn both the API of the ORM and SQL. It does not absolve you from learning SQL, which I think was one of the unstated attrac…

> I now believe it's better to use SQL directly than to use an ORM I reached the same conclusion. Everything is so much simpler that way. I ask the database for the data, the database gives it to me. That's the end of it. I used to like highly abstract libraries but the truth is they provide the lowest common denominator in features at a huge cost in complexity. Now I'd rather work as closely to the implementation as…

ORMs are great when you have to update large graphs of objects. They are not great for querying. The performance of querying is so unpredictable in an ORM that it's better to handle these read queries by hand. Things that tend to screw up performance are the N+1 query problem and generated SQL causing bad query plans. One needs to get to know one's database query planner in order to get the best performance, and that requires dealing with the raw SQL.

Re: Prisma – ORM for Node.js and TypeScript

#236

Post by rafaelvasco »

I use Mikro-ORM not Prisma but I couldn't help but use an ORM in my project. Dealing with Mongodb schemas and queries directly, and modelling associations between entities, hiding certain fields on select, selectively populating joined @ManyToOne properties and all that DB stuff, was a nightmare to do by hand. Changed everything to ORM and all my problems were solved. Annotated entities, annotated properties, queries, joins, hidden fields, @OnCreate triggers etc, everything nicely handled for me. So yeah, I love ORMs. Have yet to find something nicer than .NET Entity Framework + LINQ though. That stuff is amazing.

Re: Prisma – ORM for Node.js and TypeScript

#237

Post by ysavir »

jdc0589 wrote: post #222
rendall wrote: post #221

Earlier quoted context omitted.

I despise ORMs. I don't judge programmers very often, but invariably if there is an ORM, there is a fragile, tightly coupled, difficult-to-maintain project nearby

currently staring at what's left in a large legacy rails/activerecord app figuring out what to do with. the suffering is real.

What obstacles are you hitting?

Re: Prisma – ORM for Node.js and TypeScript

#239

Post by presentation »

hardwaresofton wrote: post #65
presentation wrote: post #42

Earlier quoted context omitted.

TypeORM is poorly maintained (the lead author had a breakdown and appears to be inactive, and failed to delegate ownership to others), and is riddled with bad abstractions, poor design choices and an enormous pile of game-breaking bugs that make the TypeScript types unsafe and it’s usage clunky and dangerous. I would absolutely use knex, which works, over TypeORM, which routinely doesn’t.

Interesting -- I actually haven't had as many problems as you have with TypeORM -- it's just mostly worked. Then again, maybe I'm a rare case, because I basically ignore the ORM side and use a little repository pattern, the query builder, and write my own migrations in SQL (as in all the migrations are `await queryRunner.query(...);`). It's been excellent for me -- I ignore the bad abstractions, have a good underlyin…

Yeah my issues are from trying to actually use the advertised functionality of the library. Issues include migrations being generated incorrectly, lots of footguns (for example it’s extraordinarily easy to instead of deleting a particular row, to delete your whole table, and their typescript typings are too general to make it clear what you’re doing), the pattern of making instances of relations that lack all the fields that are required in the DB leads to the type system becoming unreliable (fields that should always be present in the DB, may not be in JS), transformer functionality has a ton of bugs as well. I’m just scratching the surface, it’s telling that there are 1500+ unresolved issues on the repo and 200+ unmerged PRs.

The downside for me about dropping into raw SQL is that it makes much of the usefulness of an ORM in being able to refactor your schema and stuff disappear, because the type system and instrumentation can’t auto-refactor a raw SQL string. But I agree that I’d take that over relying on TypeORMs bugginess.

Post reply on HN