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

151–160 of 260 posts

Re: Prisma – ORM for Node.js and TypeScript

#151

Post by lostcolony »

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 have yet to find the person who, being comfortable with both raw SQL and a particular ORM, to, when faced with the choice of learning a new ORM or using raw SQL, reach for the new ORM. To be honest, I haven't met in person anyone who reached for the familiar ORM, either, for anything complex in a team environment, but that's a more aggressive statement.

I mention this because to my mind it reinforces my belief that learning an ORM (which I've done in the past, and then never used again) isn't worth the effort; learning SQL is, if for no other reason than it's portable (and you'll have to learn it anyway when the ORM's abstraction leaks).

Re: Prisma – ORM for Node.js and TypeScript

#152

Post by wdb »

tomhoule wrote: post #136
abaldwin99 wrote: post #77

I'm completely perplexed at some of the functionality that's absent in Prisma? I'm coming from the Rails/Django world for reference. Can anyone help me understand if I'm out in left field or does this technology only cover basic use cases? - No supported way to do a case-insensitive sorting. https://github.com/prisma/prisma/issues/5068 - Can’t sort by an aggregate value like user’s post count. https://github.com/pris…

I can clarify one point, relative to migration rollbacks. We indeed chose not to implement down migrations as they are in most other migration tools. Down migrations are useful in two scenarios: in development, when you are iterating on a migration or switching branches, and when deploying, when something goes wrong. - In development, we think we already have a better solution. Migrate will tell you when there is a d…

This sounds like you aren't able to easily rollback a release that had migrations

Re: Prisma – ORM for Node.js and TypeScript

#153

Post by tored »

nicoburns wrote: post #49
nikolasburk wrote: post #30

Earlier quoted context omitted.

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…

> 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. I'm not sure about that. We've recently switched from JavaScript based querying code to mostly raw SQL, and we've reduced our code to about 25% of what it was, and it's much simpler to understand than it was befo…

I think the strongest argument for or against an ORM is that it changes the structure of your code, how you reason about your data.

Things like performance, ease of use, reusability, schema generation etc are minor points and not the big issue you need to think about.

Personally I feel that an ORM will lead your project in the wrong direction and your database schema will suffer.

ORMs will usually mix both reading and writing within the same class, but those are not the same thing.

Readers will have different views of your model depending on who they are or what time it is. Writing on the other hand must fulfill your constraints.

Other common mistakes of ORMs is mapping one class with one table, but your data consist of series of relationships, that can’t be explained with a class.

An ORM creates an illusion that your data is actually the class entities in your repository. This can have the effect of creating constraints in your own mental model of your data, thus making it harder to evolve your schema because you are to fixed on how your classes are designed.

Re: Prisma – ORM for Node.js and TypeScript

#154

Post by nikolasburk »

wdb wrote: post #148
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…

It's unclear what's the pros are of Prisma compared to TypeORM. I do find it confusing I always thought Prisma was GraphQL related.

> I do find it confusing I always thought Prisma was GraphQL related.

This is a common misconception that stems from our history as a company and being early contributors to the GraphQL ecosystem. With the move to Prisma 2 however, there is no native GraphQL layer in Prisma any more. I've talked about this extensively in a recent livestream on Youtube [1] if you want to learn more :) There's also this article "How Prisma and GraphQL fit together" [2] that explains the historic dimensions of this if you're interested.

> It's unclear what's the pros are of Prisma compared to TypeORM.

I guess you could argue that one benefit is the superior type-safety Prisma provides [3]. Other folks have also called out that they prefer way how data is modeled with Prisma (via the Prisma schema), the migration system as well as the active maintenance, regular releases, the active community, the support and thorough documentation of Prisma. Ultimately it'll come down to your personal preference though which one is the more appropriate for your project :)

[1] https://www.youtube.com/watch?v=hMWMPpy4ta4&list=PLz8Iz-Fnk_...

[2] https://www.prisma.io/blog/prisma-and-graphql-mfl5y2r7t49c

[3] https://www.prisma.io/docs/concepts/more/comparisons/prisma-...

Re: Prisma – ORM for Node.js and TypeScript

#155

Post by hnjobaccount »

mixedCase wrote: post #116
eurasiantiger wrote: post #28

Earlier quoted context omitted.

> 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).

Here's a small article that explains how the dataloader pattern works under the hood https://www.mikealche.com/software-development/advanced-prom...

Re: Prisma – ORM for Node.js and TypeScript

#156

Post by hnjobaccount »

dickfickling wrote: post #29
brap wrote: post #25

Earlier quoted context omitted.

> GraphQL N+1 issues are a thing of the past. Huh, care to explain this one? I’m using Prisma with Apollo Server without doing anything fancy in my resolvers. I just assumed I’m getting N+1 issues but didn’t bother to optimize yet.

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.

For the interested, here's an article that explains how the dataloader manages to pull this off https://www.mikealche.com/software-development/advanced-prom...

Re: Prisma – ORM for Node.js and TypeScript

#157

Post by databrecht »

yewenjie wrote: post #45

I am a noob in these matters which one is advised if one is to start a GraphQL API from the beginning - use DBs that directly provide GraphQL endpoints such as Fauna, Upstash, etc. - use an ORM with more traditional DBs. What are the pros and cons of each?

There is value in both, at Fauna we provide GraphQL out the box. Using Fauna directly would eliminate an indirection and is probably slightly more efficient. However, if there is a GraphQL layer like Prisma in between you could essentially change to any database with less impact on your application. This is tremendously interesting for people who develop frameworks, using prisma gives them the advantage of supporting multiple databases immediately. Or for application developers it could allow you to move from a non-scalable database to a scalable database once it becomes necessary or simply just switch databases if the database maintenance is causing you grief. I'm for one looking forward to Prisma supporting Fauna since if the interface is the same, there are even less reasons not to choose a scalable managed database instead of managing your own db :). And I would say that Prismas interface is quite great!

Note: the performance impact does depend heavily on whether your database maps well on ORMs. Traditional databases have an impedance missmatch when it comes to translating tables to an objet format. Graph databases or the way Fauna works (documents with relations and map/reduce-like joins) map well on ORMs so the performance impact would be small.

Re: Prisma – ORM for Node.js and TypeScript

#158

Post by kofejnik »

Used it once, it is nice(-ish) for simple use cases, but unfortunately it doesn't support working with multiple postgres schemas, which is surprising given that many complex apps use them to namespace their DBs. It was a total showstopper for us and we're back to writing raw sql for now

Re: Prisma – ORM for Node.js and TypeScript

#159

Post by thedavidprice »

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…

I'm on the RedwoodJS core team and can 100% confirm early performance issues. That's no longer been the case recently. I've seen bulk operations perform just fine and even data pipeline use cases. Now the issue is DB performance in a serverless infra, which needs extra set up and config to perform consistently and at scale.

Re: Prisma – ORM for Node.js and TypeScript

#160

Post by cknoxrun »

whatl3y wrote: post #26
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.

While some people are hard lined enough on their anti-ORM stance that it sort of becomes weird, I agree with you that my beef with ORMs comes from being burned before a couple of times by a super inefficient aggregation ActiveRecord did on GROUP BY queries that it 1. not only took a really long time to figure out why a particular page in our app was loading slow but 2. we ended up having to write raw SQL to fix it. I…

Not sure when you used ActiveRecord, but slow query logging helps a lot to identify these issues. I also appreciate that in the docs for ActiveRecord they make it very clear that jumping to raw SQL is absolutely fine and normal, and they make the interface for doing that very nice.
Post reply on HN