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

61–70 of 260 posts

Re: Prisma – ORM for Node.js and TypeScript

#61

Post by sbarre »

eurasiantiger wrote: post #33
dickfickling wrote: post #29

Earlier quoted context omitted.

in short the separate engine process allows them to combine every findX call you make during one tick of the event loop into a single SQL query, following the dataloader pattern, so you don’t have to implement it yourself. i’m sure @nikolasburk can shed some more light if you’re interested.

I have a feeling that does not work at all in non-trivial scenarios, e.g. if both composite keys and date range matching are required to resolve a reference.

Could you test this and get back to us with the results?

Re: Prisma – ORM for Node.js and TypeScript

#63

Post by abraxas »

nikolasburk wrote: post #30
loloquwowndueo wrote: post #3

“ Application developers should care about data – not SQL” Anyone who has been bitten by an ORM generating inefficient SQL (and subsequent having to learn and care about SQL) knows the above not to be true.

This statement is certainly provocative (great that it was the first thing picked up here :D) but I'm happy to explain our rationale for this a bit more. SQL is an impressive technology and has stood the test of time! Yet, we claim that it's not the best tool for application developers who are paid to implement value-adding features for their organizations. SQL is complex, it's easy to shoot yourself in the foot with…

I think SQL gets a lot of undeserved praise that I’m having a difficult time understanding. The only impressive thing about SQL is its prevalence but that’s a pretty poor yardstick unless one thinks that an appeal to popularity is an indicator of quality.

Now let me count the ways in which SQL is bad:

- it composes poorly due to its unwieldy cobolesque syntax

- it is a leaky abstraction revealing a lot of underlying implementation tradeoffs

- it doesn’t properly implement Cobb’s relational model

- it is poorly standardized with a ton of proprietary extensions and alterations present in virtually every implementation

- it is still poorly supported by tools because the model metadata lacks any standard interface to make universal tooling possible

A lot of the praise for SQL is just bandwagon hopping and cargo cult behaviour or a lack of vision by most people of how things could be much better

Re: Prisma – ORM for Node.js and TypeScript

#64

Post by vbsteven »

brap wrote: post #17

I’ve been using Prisma for a while and I quite like it. Best ORM for TypeScript I’ve used. My biggest issue with it is testability. Sure, I can mock the Prisma client in tests with Jest or something, but if I want to test state I pretty much have to reimplement an in-memory DB using JS mocks. I can also connect to a real DB made for testing but it’s quite overkill, I’m usually not interested in testing Prisma itself,…

Could you elaborate on why you find a real DB overkill for testing purposes?

Typically you would have a set of unit tests which test your code only and use mocks for external dependencies, in this case you would mock Prisma.

Tests involving DB state are not unit tests anymore and require a bit more setup but most frameworks provide a test harness/runner to quickly spin up a part of your app with dependencies resolved (instead of mocked) so you can call controller/handler/service methods directly and verify their behavior.

The boilerplate for this should mostly be limited to switching out an environment variable for the database connection and maybe setup some fixtures. Is this not possible in Prisma?

Re: Prisma – ORM for Node.js and TypeScript

#65

Post by hardwaresofton »

presentation wrote: post #42
williamdclt wrote: post #10

Earlier quoted context omitted.

(haven't tried Prisma) TypeORM -> classic ORM, the "default" choice in node, but not very mature compared to what exists in Java or things like Django ORM. In my experience it's not an amazing lib, transaction management is a bit painful, I've seen a couple bugs happen. Knex -> it works but not sure why you'd use that rather than TypeORM MikroORM -> not a lot of experience, one of my colleagues really likes it, read…

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 underlying database (postgres), and drop down to parametrized raw SQL whenever I need to, it's held up extraordinarily well I think.

Could you expand on some specific issues/frustrations? Just curious about the side I'm clearly not seeing.

Re: Prisma – ORM for Node.js and TypeScript

#67

Post by ragnese »

brap wrote: post #17

I’ve been using Prisma for a while and I quite like it. Best ORM for TypeScript I’ve used. My biggest issue with it is testability. Sure, I can mock the Prisma client in tests with Jest or something, but if I want to test state I pretty much have to reimplement an in-memory DB using JS mocks. I can also connect to a real DB made for testing but it’s quite overkill, I’m usually not interested in testing Prisma itself,…

Isn't that pretty much always the dilemma with database stuff and testing?

On the one hand, you can wrap your DB operations in some kind of mockable interface(s), and then test your business logic.

On the other hand, you really need to test that the actual SQL ops work anyway- what if you screwed up a foreign key constraint?- that wouldn't show up in your business logic tests or your in-memory SQLite or whatever.

Re: Prisma – ORM for Node.js and TypeScript

#68

Post by nesarkvechnep »

dickfickling wrote: post #19

I LOVE Prisma. I’ve used Django, SQLAlchemy, Sequelize, Knex, and TypeORM in the past. all had rough edges that continually frustrated me or didn’t provide the functionality i needed. Prisma is different. It’s absolutely got rough edges, but the extremely strong type safety makes Sequelize look like a joke. The query engine itself, written in rust, combines and optimizes queries inside every tick of the event loop so…

You haven't mentioned the best query builder I've ever used - Elixir's Ecto. I encourage to give both Elixir and Ecto a try as they're worth learning.

Re: Prisma – ORM for Node.js and TypeScript

#69

Post by dickfickling »

brap wrote: post #43
dickfickling wrote: post #29

Earlier quoted context omitted.

in short the separate engine process allows them to combine every findX call you make during one tick of the event loop into a single SQL query, following the dataloader pattern, so you don’t have to implement it yourself. i’m sure @nikolasburk can shed some more light if you’re interested.

Very interesting, thank you. Is there a way for me to monitor what Prisma is doing in my use case?

using `new PrismaClient({ log: ["query"] });` it'll log all the actual sql queries it's running, so you'll be able to see if queries are being combined

Re: Prisma – ORM for Node.js and TypeScript

#70

Post by einrealist »

loloquwowndueo wrote: post #3

“ Application developers should care about data – not SQL” Anyone who has been bitten by an ORM generating inefficient SQL (and subsequent having to learn and care about SQL) knows the above not to be true.

I agree.

That statement is so wrong. All ORMs suffer from leaky abstraction. And good ORMs would never hide that fact, nor would they try to deny native access to the database and force a all-or-nothing principle onto the developer.

If "application developers" care about data that is stored in a relational database, they have to care about the database itself and the access patterns (SQL).

ORMs _only_ provide convenience! They cannot substitute knowledge about the underlying technologies. And they cannot hide complexity, but shift it to the ORM.

Post reply on HN