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

171–180 of 260 posts

Re: Prisma – ORM for Node.js and TypeScript

#171

Post by Boxxed »

nikolasburk wrote: post #137
vptr wrote: post #131

Earlier quoted context omitted.

I have no idea what this means either. Sounds like a bunch of buzzwords about nothing.

It means that Prisma will provide a data access layer (we call it "application data platform" [1]) similar to the custom data access layers built by big companies [2] (e.g. TAO by Facebook or Strato by Twitter) that enables application developers to better access their databases. We've explained that in the blog post here in the "Open-source, and beyond"-section [3]. Does that help? :) [1] https://imgur.com/O1lwo0v.p…

I think we all appreciate the links but unless I'm missing something, no, it doesn't help -- what's the plan to make money? That blog post doesn't mention anything along those lines at all.

Re: Prisma – ORM for Node.js and TypeScript

#172

Post by abaldwin99 »

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…

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?

Re: Prisma – ORM for Node.js and TypeScript

#173

Post by mst »

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…

Spinning up a temporary e.g. postmaster instance for a test off a pre-built data directory (bonus: use zfs or btrfs or similar snapshots to make this even faster) is, IME, while still effectively "completely recreate" also both much more robust than wrap-in-transaction and generally not the slowest thing about your tests (and of course allows reliable parallelisation).

Bit of setup effort but well worth it IME even in situations where your tooling isn't strongly pushing you towards the approach.

Re: Prisma – ORM for Node.js and TypeScript

#174

Post by vaughan »

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.

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

SQL has always been a sort a magical, black-box in that you have very limited control over the query planner, and have to hint at it to do the right thing. (I guess `EXPLAIN` allows you to peak in the box a little)

I found [Apache Calcite](https://calcite.apache.org/docs/algebra.html) rather interesting. It provides the primitives that a DBMS is built from.

I would be interested to compare how PSQL is built in comparison. I would love a more layered/pluggable database that everyone can build off of. I think FoundationDB had this approach.

Re: Prisma – ORM for Node.js and TypeScript

#175

Post by alireza94 »

loloquwowndueo wrote: post #76
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…

Oh don’t get me wrong - ORMs have their place and do enable higher agility. They do seem magical the first time you encounter them. What I object to is the blanket “shouldn’t care about sql” statement because that’s what empowers people to use the ORM indiscriminately without understanding what’s under it (an understanding for which SQL is relevant) and then it’s the non-value-adding developers’ job to come in and un…

Exactly. ORMs, especially powerful and mature ones like DjangoORM or Active Record, can help with productivity and maintainability and for more complex use cases you have the chance to switch to raw SQL; However, it’s important for developers to know what’s happening under the hood and to know what will happen if they use a certain feature of an ORM. I can’t even count the number of times that when one of my coworkers and I tried to fix a performance issue, and after digging deep into queries and mechanics of the ORM, we’ve realized how ORM heed so much complexity from them and, how a certain data structure design and coding in a certain way can result in an inefficient data flow.

Re: Prisma – ORM for Node.js and TypeScript

#176

Post by mst »

codeulike wrote: post #122

New idiom - "Well that was a complete ORM" (sorry just a joke, ORMs do have their place and this looks useful. I'd think of Prisma as a lightweight ORM because it doesn't try to do "Business Rules" as they are known. But then, trying to do Business Rules will generally turn everything into a nightmare anyway so maybe lightweight ORM is the way to go)

Even as an ORM author this made me laugh.

ORMs are useful. ORMs aren't always the right answer. ORMs that don't let you mix and match so you can bypass any given layer of abstraction as required annoy the pants off me ... usually even more than anti-ORM zealouts annoy the pants off me.

So, yeah, joke appreciated :D

Re: Prisma – ORM for Node.js and TypeScript

#177

Post by megous »

intergalplan wrote: post #145
megous wrote: post #108

Earlier quoted context omitted.

Actually nested objects kinda suck even for frontend devs, if you're trying to keep things in sync efficiently. Often times it's much better to be able to lookup some object by ID of the entity from some Map, than consuming endpoints returning some crazy nested partial data for the current view. Depends on how much your app relies on client side caching and incremental sync of data.

As soon as you need a lot of complex data all displayed in one place plus high performance, you're gonna find you need a list , not a hierarchy. You need to be able to treat the data coming in like a stream, not to traverse anything. Read the row, maybe do some state-machine stuff to decide how to treat it, then drop all that on the floor and move to the next row. This is more-true the less efficient the language is…

That too. Though I used efficiently in a sense of minimizing the communication between client/server by normalizing data and just sending changes.

Which is easier if you keep data normalized on the client side too, and look up related objects in a Map when needed, instead of keeping multiple copies of objects representing the same entity everywhere in your client code in some/vasrious denormalized forms.

It would actually be very nice for some use cases if I had a SQL interface to local data on the client side too, so that I can query/join them up arbitrarily as needed from what's loaded up to client storage. That's unpleasant to do in the browser with current platform APIs.

Basically I want WebSQL back in some form, instead of this IndexedDB thing. :)

Re: Prisma – ORM for Node.js and TypeScript

#178

Post by vaughan »

megous wrote: post #108
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…

Actually nested objects kinda suck even for frontend devs, if you're trying to keep things in sync efficiently. Often times it's much better to be able to lookup some object by ID of the entity from some Map, than consuming endpoints returning some crazy nested partial data for the current view. Depends on how much your app relies on client side caching and incremental sync of data.

> if you're trying to keep things in sync efficiently

I think we are all abusing GraphQL in this sense. Caching GraphQL data is a world of hurt.

The easiest way to sync is if your data is in the same model as the way it is stored, which is normalized if using SQL. Even when we do normalize most people will represent a 1-M as an array of foreign keys: `posts.comments = [1, 2, 3]` when in the db we use a foreign key on the `comment` entity: `comment.post_id = 1`. This causes such headaches for optimistic UI updates. It's a mess.

We should be using GraphQL to retrieve data and then render it directly.

Ultimately, I think we should be implementing our GraphQL API client-side against a local SQL DB that acts as a pass-through cache. Then your entire app runs offline and instantly respond to queries eliminating the need for a separate client-side cache, and you don't have to worry about about data model mismatch anymore.

> Depends on how much

I think all apps want this - unless they are SSRing with <100ms on every action.

Re: Prisma – ORM for Node.js and TypeScript

#179

Post by megous »

vaughan wrote: post #178
megous wrote: post #108

Earlier quoted context omitted.

Actually nested objects kinda suck even for frontend devs, if you're trying to keep things in sync efficiently. Often times it's much better to be able to lookup some object by ID of the entity from some Map, than consuming endpoints returning some crazy nested partial data for the current view. Depends on how much your app relies on client side caching and incremental sync of data.

> if you're trying to keep things in sync efficiently I think we are all abusing GraphQL in this sense. Caching GraphQL data is a world of hurt. The easiest way to sync is if your data is in the same model as the way it is stored, which is normalized if using SQL. Even when we do normalize most people will represent a 1-M as an array of foreign keys: `posts.comments = [1, 2, 3]` when in the db we use a foreign key on…

Ha :) Yeah, I just replied in a similar vein in the other reply to my original comment. Agreed!

Re: Prisma – ORM for Node.js and TypeScript

#180

Post by tomhoule »

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?

As of now there is no strong opinionation in the tool — you could absolutely maintain a set of down migrations to recover from bad deployments next to your regular migrations, and apply the relevant one (manually, admittedly) in case of problem.
Post reply on HN