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

191–200 of 260 posts

Re: Prisma – ORM for Node.js and TypeScript

#191

Post by nawgz »

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 think the industry is strangely blind to the consequences of this

Well, I think if you're not blind to those things to some degree, you're stuck forever in a best-practices search, which I feel like more often than not ends up implying you have to rewrite your stack.

For example, I do most of my development thru Hasura now. It writes insanely performant SQL queries translated directly from GraphQL. As a data consumer, you only have to worry about the shape of the data you want, and none of the implementation details. There is one endpoint, and you pass it queries against the schema it exposes. Implementation details are abstracted heavily here, but in a "good" separation of concerns way.

I will never hand-write SQL again. Why would I? My front-ends can load everything in my data model expressively and with type safety thanks to graphql-codegen.

Now imagine you read this and realize you work in a completely different method and this answers some of your problems. You may start parallel development, but you certainly can't stop forward progress just to evaluate your stack. So I think the blinders are key to progressing in the short term despite the productivity losses you're taking in the long term, and then when you phrase it like this it is surely no surprise companies behave like that.

Re: Prisma – ORM for Node.js and TypeScript

#192

Post by swyx »

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…

to wit: how exactly does Prisma make money?

Re: Prisma – ORM for Node.js and TypeScript

#193

Post by notJim »

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…

> We've recently switched from JavaScript based querying code to mostly raw SQL

Curious what your use case is, because in every codebase I've worked on, people pretty quickly get tired of writing out SELECT * FROM [table] WHERE id=? and UPDATE [table] SET field=? and looping over database cursors all day, and you end up with a half-done, buggy non-ORM.

Re: Prisma – ORM for Node.js and TypeScript

#194

Post by eloff »

nawgz wrote: post #191
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 think the industry is strangely blind to the consequences of this Well, I think if you're not blind to those things to some degree, you're stuck forever in a best-practices search, which I feel like more often than not ends up implying you have to rewrite your stack. For example, I do most of my development thru Hasura now. It writes insanely performant SQL queries translated directly from GraphQL. As a data cons…

> Well, I think if you're not blind to those things to some degree, you're stuck forever in a best-practices search, which I feel like more often than not ends up implying you have to rewrite your stack.

Can you expand on that? The chain of reasoning is probably clear to you, but I can't follow it.

> For example, I do most of my development thru Hasura now. It writes insanely performant SQL queries translated directly from GraphQL. As a data consumer, you only have to worry about the shape of the data you want, and none of the implementation details. There is one endpoint, and you pass it queries against the schema it exposes. Implementation details are abstracted heavily here, but in a "good" separation of concerns way.

I like Hasura a lot, I've advocated it at a previous company I worked for, and after many months of meetings I got it approved to add to our stack - which was then never prioritized, but that's another story.

> I will never hand-write SQL again. Why would I? My front-ends can load everything in my data model expressively and with type safety thanks to graphql-codegen.

I don't think writing GraphQL is superior to writing SQL, and again you have to think not just in terms of GraphQL but also in terms of how Hasura translates that to SQL under the hood. I am slightly biased though, because I'm creating on a framework to query the db using SQL from the frontend, I'm curious how you think that would compare with Hasura: https://github.com/sqljoy/sqljoy

> Now imagine you read this and realize you work in a completely different method and this answers some of your problems. You may start parallel development, but you certainly can't stop forward progress just to evaluate your stack.

I'm not really sure how this connects to my argument about complexity, although I think the link is clear to you, can you expand on that?

Re: Prisma – ORM for Node.js and TypeScript

#195

Post by karmakaze »

I was reading through the 'where' cases to see how complex queries are composed. I couldn't find any examples. e.g.

  WHERE id IN ()
if I built up using the ORM.

The other uncommon thing I look for is eliminating N+1 not just based on a given query and related entities, but given a starting collection and loading their related entities and further related entities.

Icing is if it can do all the above while making intermediate results asynchronously available as it works through it all.

Re: Prisma – ORM for Node.js and TypeScript

#196

Post by eloff »

swyx wrote: post #192
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…

to wit: how exactly does Prisma make money?

I think they don't, yet. I'm sure they have a plan for that, probably some kind of managed cloud service.

Re: Prisma – ORM for Node.js and TypeScript

#197

Post by friend-monoid »

jcpst wrote: post #35
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 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…

Right. Data management is a hard problem. Just look at SQL query planners, they are insane - but they are not perfect, and they only work on the premises you provide (schemas, indexes, memory, etc). The idea that you could introduce a library that fixes all data management issues for you is not well considered.

Re: Prisma – ORM for Node.js and TypeScript

#198

Post by wasd »

How's the support for window functions? One thing I like about ActiveRecord is it's lazily evaluated and you compose queries. You can do p = Post.where(published: true); if x; p.where(x: true). Is that supported?

Checked here for window function support. https://www.prisma.io/docs/concepts/components/prisma-client...

Re: Prisma – ORM for Node.js and TypeScript

#199

Post by dickfickling »

swyx wrote: post #192
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…

to wit: how exactly does Prisma make money?

https://news.ycombinator.com/item?id=26888735

Re: Prisma – ORM for Node.js and TypeScript

#200

Post by smt88 »

jadbox wrote: post #190
smt88 wrote: post #112

Earlier quoted context omitted.

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

Have you compared PgTyped to Zapatos (I haven't yet).

Not yet, but I will at some point. I don't really have any pain points with pgTyped yet.
Post reply on HN