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

251–260 of 260 posts

Re: Prisma – ORM for Node.js and TypeScript

#251

Post by caspar »

jdc0589 wrote: post #248
ysavir wrote: post #237

Earlier quoted context omitted.

What obstacles are you hitting?

the active record pattern, as it is commonly used, does not set you up well to lift individual components out of a monolith.

Perhaps you already have ideas on how to solve for this situation, but in case it helps: forcing active record model accesses to go via a layer of indirection can help with untangling this sort of thing: https://kellysutton.com/2019/10/29/taming-large-rails-codeba...

That said, for microservice extraction specifically, a bit of creative metaprogramming/monkey patching of AR to identify & categorize your callers is probably easier.

Re: Prisma – ORM for Node.js and TypeScript

#252

Post by jcrben »

nikolasburk wrote: post #154
wdb wrote: post #148

Earlier quoted context omitted.

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 Pr…

I skipped Prisma when I discovered that you were supposed to toss your schema in a single file. There's some ways to get around this but amazed that this is the official way

Re: Prisma – ORM for Node.js and TypeScript

#253

Post by nwienert »

sbacic wrote: post #246
nwienert wrote: post #242

Earlier quoted context omitted.

Hard to remember them all now, but definitely had a number of bugs I've ran into, most able to be worked around. For example a recent one was a huge slowdown in a simple query that should be optimized[0], still have no great solution for it or attached to any roadmap. One big one is at some point you need caching on a query level, and for that you have to purchase enterprise. I suppose they need to make money somehow…

Yikes! That sounds like it has "vendor lock-in" written all over it.

Yea, but it’s a lot better than what’s out there, as far as I know, even with Postgraphile having progressed a lot.. and it is open source.

Re: Prisma – ORM for Node.js and TypeScript

#254

Post by Apofis »

m007850 wrote: post #244
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.

This isn't true. Prisma currently only supports batching of findUnique queries: https://www.prisma.io/docs/guides/performance-and-optimizati... There's an issue open for findMany as well, but it hasn't moved in over a year: https://github.com/prisma/prisma/issues/1477

Is 933 open issues a warning sign? Seems excessive.

Re: Prisma – ORM for Node.js and TypeScript

#255

Post by presentation »

hardwaresofton wrote: post #250
presentation wrote: post #239

Earlier quoted context omitted.

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 fie…

Thanks for sharing this insight, it makes a lot more sense to me now, saving this (in my brain) for the counter argument to TypeORM. > I’m just scratching the surface, it’s telling that there are 1500+ unresolved issues on the repo and 200+ unmerged PRs. So just a side note on this, I judge repositories based on teh ratio of closed to unresolved (and whether they have a bot that auto-closes issues). 200+ unmerged PRs…

Yeah, a lot of people have been saying that on the pinned mega-issue re the future of TypeORM - but the maintainer doesn't seem to have done much to fundraise nor pass on leadership to others. This seems to be moving slightly - some contributions are slowly trickling in. But at this point I think alternatives like Prisma will just eat the pie.

Re: Prisma – ORM for Node.js and TypeScript

#256

Post by presentation »

nikolasburk wrote: post #117
sickcodebruh wrote: post #113

Earlier quoted context omitted.

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

I think you meant from TypeORM to Prisma

Re: Prisma – ORM for Node.js and TypeScript

#257

Post by tor291674 »

agustif wrote: post #37
CGamesPlay wrote: post #23

I have adopted Prisma in my latest project and I have mixed feelings about it. - The generated client is top-tier. Fully specified in TypeScript with intelligent types that can be extended by the user. - The schema language is great. It provides a cohesive experience that can fully express your database structure, and it also provides a migration framework to manage that structure's evolution. - There's no hook for i…

Hey totally off-topic maybe as it's not prisma-related/required. What do you think of using something like msw.io for mocking your endpoints as needed?

> msw.io

The website is https://mswjs.io/

Re: Prisma – ORM for Node.js and TypeScript

#258

Post by tor291674 »

abaldwin99 wrote: post #172
tomhoule wrote: post #136

Earlier quoted context omitted.

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…

So future features notwithstanding, is the typical Prisma workflow that if a migration failed during a production deploy the developer would have to manually work out how to fix it while the application is down?

Take a backup before you do any prod migrations.

Re: Prisma – ORM for Node.js and TypeScript

#259

Post by jdc0589 »

caspar wrote: post #251
jdc0589 wrote: post #248

Earlier quoted context omitted.

the active record pattern, as it is commonly used, does not set you up well to lift individual components out of a monolith.

Perhaps you already have ideas on how to solve for this situation, but in case it helps: forcing active record model accesses to go via a layer of indirection can help with untangling this sort of thing: https://kellysutton.com/2019/10/29/taming-large-rails-codeba... That said, for microservice extraction specifically, a bit of creative metaprogramming/monkey patching of AR to identify & categorize your callers is pr…

the data access abstraction layer is absolutely the "right" move. just hard to stomach the amount of work involved that's ultimately kind of throw-away.

the problem with activerecord is most people usually don't put this in place to begin with because the active record pattern makes it easy not to, which creates a massive pile of spaghetti code long term.

Re: Prisma – ORM for Node.js and TypeScript

#260

Post by abaldwin99 »

tor291674 wrote: post #258
abaldwin99 wrote: post #172

Earlier quoted context omitted.

So future features notwithstanding, is the typical Prisma workflow that if a migration failed during a production deploy the developer would have to manually work out how to fix it while the application is down?

Take a backup before you do any prod migrations.

Sure we do that before every release as well. But a rollback is a much less invasive surgical fix compared to a full database restore. You're down while the new db instance spins up and any writes in the meantime will be lost.

You can also test migrations against a restored prod database snapshot but again there's no guarantee some incompatible data hasn't been inserted in the meantime.

Post reply on HN