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

111–120 of 260 posts

Re: Prisma – ORM for Node.js and TypeScript

#111

Post by nerdkid93 »

Over a year ago, I was investigating using Prisma to be the ORM for a GraphQL API of a Postgres database. When doing a proof-of-concept, I discovered that under the hood @prisma/client was spinning up it's own GraphQL server that it would send requests to in order to generate SQL to send to postgres. This extra middleware layer between my frontend code and postgres generated some pretty poor performing queries that took 50% longer to complete than the queries generated by using Hasura as our whole GraphQL API.

A quick glance at the @prisma/client code makes it seem like this pattern is still the case, since they have an "engine-core" package that downloads a binary server behind the scenes and runs it on a free port in the background.

Re: Prisma – ORM for Node.js and TypeScript

#112

Post by smt88 »

skrebbel wrote: post #88

IMO any discussion about Node/TypeScript data access tools deserves a reference to Zapatos, which sort of is the anti-Prisma. It has all the type safety with none of the ORM (and it's Postgres-specific, for better and worse). I think it's got one of the best designed APIs I've come across. https://jawj.github.io/zapatos/

PgTyped is similar, and it's superior to any other data access layer I've ever used. Ever.

Re: Prisma – ORM for Node.js and TypeScript

#113

Post by sickcodebruh »

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.

This matches my team’s experience with TypeORM. It’s full of bad surprises. We use it exclusively with a read-only account because we don’t trust it to change our data under any circumstance. Our current plan is to move to MikroORM, Prisma 2, or just give up on Node completely.

Re: Prisma – ORM for Node.js and TypeScript

#114

Post by sickcodebruh »

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…

This is the one upside I’ve had of using TypeORM: I find its query abstractions so unreliable and surprising that it’s forced me to get better at SQL!

Re: Prisma – ORM for Node.js and TypeScript

#115

Post by megous »

molf wrote: post #54
kami8845 wrote: post #38

Earlier quoted context omitted.

While depending on a live DB for testing isn't great, why not just blow away database state after every test by running TRUNCATE / DELETE against all tables? DELETE especially is very fast (couple ms) if you're not inserting large amounts of data during your test runs.

1) You can't run tests in parallel. 2) It is at least an order of magnitude slower than not using a database at all. Combined this makes for very slow tests. Certainly for larger applications with thousands of tests. Having said that, I don't think there is a single right answer to the problem of testing applications that use a database and your suggestion still can be a valid solution.

1) Actuallly you can, in multiple ways:

- parallel sessions on one database just like multiple clients accessing your web app at the same time

- create multiple copies of a schema and run different independent testusite legs on each (you just have to pass X-Test-Schema in the HTTP header to select on which schema should the web app operate)

- I have an even better trick up my sleeve for testing an app with a real DB backend, and that's passing X-Test-Force-Time header that allows me to override time under which app and DB operates per-request, so I can test even time dependent behavior, like timeouts, timed queues and events, time dependent DB queries, etc. And in general just have a stable predicatble timestamps in the database for each test run and be able to compare database states at the end of the test run and check the diff for irregularities against the previous test runs, or known good state.

I have to patch postgresql to allow for output of now() current_timestamp, etc. to be overridable per session, but it's absolutely worth it to be able to simulate/control the flow of time across the whole stack.

You can actually do a lot of useful stuff with schemas and search_paths, without disrupting connected clients, and without having to re-create databases, all in a transactional/atomic manner, that is very useful for testing.

Re: Prisma – ORM for Node.js and TypeScript

#116

Post by mixedCase »

eurasiantiger wrote: post #28
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…

> GraphQL N+1 issues are a thing of the past. This one I will believe when I see it. It would be a general solution to cache invalidation.

You can disable caching if that's a problem for your application. But the idea is that DataLoader simply holds onto promises that requested an entity, and fires them all in batches according to a scheduler function. In Node.js, the default is to use scheduler magic (relies on how the event loop works).

Re: Prisma – ORM for Node.js and TypeScript

#117

Post by nikolasburk »

sickcodebruh wrote: post #113
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.

This matches my team’s experience with TypeORM. It’s full of bad surprises. We use it exclusively with a read-only account because we don’t trust it to change our data under any circumstance. Our current plan is to move to MikroORM, Prisma 2, or just give up on Node completely.

Just as a side-note, we have migration guide from Prisma to TypeORM in our docs: https://www.prisma.io/docs/guides/migrate-to-prisma/migrate-...

Re: Prisma – ORM for Node.js and TypeScript

#118

Post by joshmanders »

htkien wrote: post #101
jcpst wrote: post #35

Earlier quoted context omitted.

I agree, and find the reluctance to care about SQL interesting. Sure, SQL is not perfect, and has it’s flaws. But instead of learning an established, declarative language designed for data access, there are developers that would much rather learn new tools and libraries to avoid it. If you need to use another programming language for data access, you’re off looking for another ORM. Or the next, better ORM of the year…

Yeah, ORMs were marketed as "if your database changes, you don't have to change anything!". What about if your programming language changes? You have to learn an entirely new ORM each time. What about all of the people who have to read your code? Which ORM's do they know? Everyone knows SQL.

> What about if your programming language changes?

Very rarely does an organization completely rewrite their products in completely different languages. And if they do, I'd hope they take the due diligence to investigate the tools they plan to switch to and make sure they are a good fit.

> You have to learn an entirely new ORM each time.

You have to learn an entirely new everything each time. ORM's aren't anything different. New language = new paradigm, new routing, new templating, new everything.

> What about all of the people who have to read your code?

What about them?

> Which ORM's do they know?

I'd assume that the team would have conversations to gather information on what ORM's everyone knows and decide which is best for their team. I don't see how this is an issue. Do you just randomly pull people into your company and just like, let them wander aimlessly?

> Everyone knows SQL.

No they don't. And if they did, a lot of stuff isn't huge massive complicated apps, most are basic CRUD apps where ORM's do all the lifting for 98% of the stuff needed done. A lot of us haven't touched SQL in so long that we couldn't construct a simple SELECT statement if we tried. I know because I wrote SQL from 2000-2014, but then tried to write a simple SELECT statement in a `pg` CLI to fetch some stuff and completely forgot how to do it.

Re: Prisma – ORM for Node.js and TypeScript

#119

Post by vptr »

nerdkid93 wrote: post #111

Over a year ago, I was investigating using Prisma to be the ORM for a GraphQL API of a Postgres database. When doing a proof-of-concept, I discovered that under the hood @prisma/client was spinning up it's own GraphQL server that it would send requests to in order to generate SQL to send to postgres. This extra middleware layer between my frontend code and postgres generated some pretty poor performing queries that t…

Yup, would not touch Prisma with a 10 foot pole

Re: Prisma – ORM for Node.js and TypeScript

#120

Post by havernator »

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.

Hard disagree. If you’re not leveraging the features of your SQL database to make your life easier, your queries faster, and keep your data consistent & valid, then you probably didn’t need SQL to begin with.

Which, yes, is a common state for many applications to be in. Wresting with SQL while using it very poorly in an effort to act like they’re not.

[edit] disagree with the quotes statement, that is, agree with the post. I worded that poorly.

[edit edit] I've been thinking about what you get from using an RDBMS while avoiding writing or knowing much about SQL or using any of the probably-extremely-nice features of your particular SQL DB (why is everyone always so eager to be DB-agnostic? If you do it right your DB will survive, and greatly ease, several rewrites of your application!) and I'm coming up with:

1) basic locking (I assume you don't want to know how to actually use transactions, beyond what your ORM does automatically, so you're just getting the basics), and

2) some probably-badly-insufficient indices, and

3) an ORM should at least get you a little normalization if you just follow patterns from its docs & examples, I suppose, though you're gonna need to understand some SQL to get much benefit out of it in your DB design and in your use of the DB, so...

An entire RDBMS seems like serious overkill if that's all you're really using.

Post reply on HN