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

211–220 of 260 posts

Re: Prisma – ORM for Node.js and TypeScript

#211

Post by dang »

Past related threads:

Prisma Raises $12M Series A - https://news.ycombinator.com/item?id=23651605 - June 2020 (111 comments)

Prisma 2.0 – Type-safe and auto-generated database client - https://news.ycombinator.com/item?id=23466834 - June 2020 (107 comments)

Prisma 2.0 Beta: Type-safe Database Access - https://news.ycombinator.com/item?id=22739121 - March 2020 (122 comments)

Comparing Database Types - https://news.ycombinator.com/item?id=21060866 - Sept 2019 (170 comments)

Prisma – Database tools for modern application development - https://news.ycombinator.com/item?id=19598287 - April 2019 (83 comments)

Show HN: Prisma – Turn Any Database into a GraphQL API - https://news.ycombinator.com/item?id=17076202 - May 2018 (16 comments)

Prisma Cloud – A GraphQL Database Platform - https://news.ycombinator.com/item?id=16529450 - March 2018 (9 comments)

Prisma – An open-source GraphQL API layer for your database - https://news.ycombinator.com/item?id=16160803 - Jan 2018 (34 comments)

Prisma: Turn your database into a real time GraphQL API - https://news.ycombinator.com/item?id=16159874 - Jan 2018 (9 comments)

Re: Prisma – ORM for Node.js and TypeScript

#212

Post by matheusmoreira »

slashdev wrote: post #188

I don't like ORMs, but Prisma is one of the better ones. It avoids a lot of shortcomings of popular ORMs. I hope they find a way to make it work as a company. I've been following them over the years from the beginning of their journey through various pivots. To use an ORM effectively you must learn both the API of the ORM and SQL. It does not absolve you from learning SQL, which I think was one of the unstated attrac…

> I now believe it's better to use SQL directly than to use an ORM

I reached the same conclusion. Everything is so much simpler that way. I ask the database for the data, the database gives it to me. That's the end of it.

I used to like highly abstract libraries but the truth is they provide the lowest common denominator in features at a huge cost in complexity. Now I'd rather work as closely to the implementation as possible. I feel like I actually understand how stuff works now.

Re: Prisma – ORM for Node.js and TypeScript

#213

Post by ragnese »

Scarbutt wrote: post #210
ragnese wrote: post #189

Earlier quoted context omitted.

Same. Honestly, I only have not-nice things to say about Node, JavaScript, and its ecosystem, so I should probably just shut up. But I was like you- I picked up Node because we had an existing project in it. It only used libraries that had the most "stars" or whatever on NPM and they were all pretty deficient (and some were shockingly slow). But none were so frustrating as Sequelize.

I only have not-nice things to say about Node, JavaScript, and its ecosystem, The NPM ecosystem can be frustrating and annoying sometimes but today nodejs is a solid server runtime.

Node-the-software-project is a feat of engineering.

But the API, the client language, the ecosystem, and even the idea are bad, IMO.

Bad API example: Tell me how to deal with time zones in Node without pulling in a big third party library. Answer: You can't. So, a "scalable" backend platform can't handle datetimes from different time zones? Neat!

"Well, that's JavaScript's fault" you say. Node certainly has (a few) APIs that don't apply to the frontend, so why not add more of the important ones for backend work?

Or, maybe JavaScript really just doesn't belong on the backend at all...

Not to mention that it's single-threaded, so the answer to scaling up better is to just run more instances. -_-

See? I should've stayed quiet. ;)

Re: Prisma – ORM for Node.js and TypeScript

#214

Post by sorenbs »

lelanthran wrote: post #82
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…

> Yet, we claim that it's not the best tool for application developers who are paid to implement value-adding features for their organizations. You have two options when marrying RDBMS SQL and OO: either mismanage the relational data so that developers can use a class hierarchy, or stop using a class hierarchy to represent data. IME, applications come and go. They get rewritten, thrown away, obsoleted. The database,…

Prisma does not use a class hierarchy that are mapped directly to tables. Instead we take advantage of structural typing to give you a very smooth developer experience that is faithful to the relational model.

Re: Prisma – ORM for Node.js and TypeScript

#215

Post by fabian2k »

slashdev wrote: post #188

I don't like ORMs, but Prisma is one of the better ones. It avoids a lot of shortcomings of popular ORMs. I hope they find a way to make it work as a company. I've been following them over the years from the beginning of their journey through various pivots. To use an ORM effectively you must learn both the API of the ORM and SQL. It does not absolve you from learning SQL, which I think was one of the unstated attrac…

I do agree with the argument that you need to understand both, the ORM and SQL. The really annoying part is that you also need to understand how the ORM translates queries into SQL to some degree.

I find ORMs very convenient and useful for simple queries, and especially for inserts/updates with many-to-many relations. And that is a very large part of a typical application. But you can very quickly meet the limits of an ORM with more complex queries, and I find it easier to just step down to SQL in those cases before learning the more complex parts of the ORM.

Re: Prisma – ORM for Node.js and TypeScript

#216

Post by TheCoelacanth »

nicoburns wrote: post #163
abraxas wrote: post #63

Earlier quoted context omitted.

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…

The great thing about SQL is the relational model. You typically can't compose parts of SQL queries easily from the programming language calling it, but SQL queries themselves compose incredibly flexibly. The result of of a SELECT query is itself a "relation" that can be queried just like a table. I do wish someone would create a compile-to-sql language that adds variables and basic conditional support. I think T-SQL…

I don't think SQL does compose well. Queries aren't first-class values in SQL.

I can write a query that queries the result of another query, but I can't store a query and then pass that somewhere to query from.

Re: Prisma – ORM for Node.js and TypeScript

#217

Post by ckmar »

slashdev wrote: post #188

I don't like ORMs, but Prisma is one of the better ones. It avoids a lot of shortcomings of popular ORMs. I hope they find a way to make it work as a company. I've been following them over the years from the beginning of their journey through various pivots. To use an ORM effectively you must learn both the API of the ORM and SQL. It does not absolve you from learning SQL, which I think was one of the unstated attrac…

PureORM[1] is an implemented thought experiment on what a "pure" object mapping library would look like - where you write regular native SQL and receive back properly structured (nested) pure business objects.

It would contrast against traditional ("stateful") ORMs which use query builders (rather than raw SQL) to return database-aware (rather than pure) objects.

The name pureORM reflects both that it is pure "ORM" (there is no query builder dimension) as well as the purity of the mapped Objects.

[1] https://github.com/craigmichaelmartin/pure-orm

Re: Prisma – ORM for Node.js and TypeScript

#218

Post by matheusmoreira »

ragnese wrote: post #213
Scarbutt wrote: post #210

Earlier quoted context omitted.

I only have not-nice things to say about Node, JavaScript, and its ecosystem, The NPM ecosystem can be frustrating and annoying sometimes but today nodejs is a solid server runtime.

Node-the-software-project is a feat of engineering. But the API, the client language, the ecosystem, and even the idea are bad, IMO. Bad API example: Tell me how to deal with time zones in Node without pulling in a big third party library. Answer: You can't. So, a "scalable" backend platform can't handle datetimes from different time zones? Neat! "Well, that's JavaScript's fault" you say. Node certainly has (a few) A…

> Not to mention that it's single-threaded, so the answer to scaling up better is to just run more instances.

Yeah, this sucks. It's impossible to do any actual processing in javascript since functions that don't return immediately will clog the event loop. Why can't we have javascript code that runs asynchronously and reports completion and results as events? Even browsers seem to have this now. I tracked issue #2133 on GitHub for a long time and nothing materialized.

Not sure if Node.js still lacks this feature. If so then it means Node.js is nothing but an I/O scripting platform. You get events and you make the system copy data from some source to some destination in response. Any sort of actual processing means latency becomes unacceptably high.

Re: Prisma – ORM for Node.js and TypeScript

#219

Post by tomhoule »

atleta wrote: post #205
tomhoule wrote: post #167

Earlier quoted context omitted.

Yep we looked at Django ORM as an inspiration. I unfortunately don't have the bandwidth right now to write a lengthy thoughtful response, but quickly on a few points: - The replaying of the migrations history is exactly what we do, but not in-memory, rather directly on a temporary (shadow) database. It's a tradeoff, but it lets us be a lot more accurate and be more accurate, since we know exactly what migrations will…

Well, of course I don't know about the internals, but having used Django migrations for a decade now (it used to be a standalone solution called "South" back then), I haven't really run into any inaccuracies and can't really imagine how those could happen. As far as I can see, the main difference is that they are storing and intermediate format (that they can map to SQL unambigously) while you immediately generate th…

It makes a lot of sense. I have a fair amount of Rails experience with ActiveRecord, and it was also my impression that the database schema drifting in development is rarely a problem, but I now think it's a bit of a fuzzy feeling and discrepancies definitely sneak in. The main sources of drift in development would be 1. switching branches, and more generally version control with collaborators, 2. iterating on/editing of migrations, 3. manual fiddling with the database

One assumption with Prisma Migrate is that since we are an abstraction of the database, and support many of them, we'll never cover 100% of the features (e.g. check constraints, triggers, stored procedures, etc.), so we have to take the database as the source of truth and let users define what we don't represent in the Prisma Schema. On SQL databases, we let you write raw SQL migrations for example, so you have full control if you need it.

Re: Prisma – ORM for Node.js and TypeScript

#220

Post by sadturnip »

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…

Afaik many of these issues are why the company i worked for ended up giving up on Prisma. We ended up switching to Objection.js.

The biggest issue was the transactions which was a non starter for us. It wasn't very helpful when after explaining our use case and being told "we are doing it wrong" in the GH discussions, and instead were told to write rollback code manually instead of using transactions was a very poor answer.

Post reply on HN