4 ms·

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

by eloff 6y ago

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 attractions to junior developers. Then you have to map between the API of the ORM and how it translates that to SQL under the hood. Then you have to understand how it handles caching and sessions and how that all works under the hood. This has been the source of so much complexity and so many bugs over the years that I no longer think the benefits are worth the cost. As always, there are exceptions and caveats, but I now believe it's better to use SQL directly than to use an ORM. In general there is too much complexity in all the layers of abstraction in software development these days, and I think the industry is strangely blind to the consequences of this. Complexity is death to software, and it should not be taken on lightly. The entire craft of a software engineer boils down to eliminating complexity and simplifying problems, the better you can do that, the more productive an engineer you will be.[1] [1] https://github.com/sqljoy/sqljoy/blob/master/docs/pages/orm.md https://github.com/sqljoy/sqljoy/blob/master/docs/pages/orm....

nawgz 6y ago
> 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.
- eloff 6y ago
  > 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 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?
swyx 6y ago
to wit: how exactly does Prisma make money?
- eloff 6y ago
  I think they don't, yet. I'm sure they have a plan for that, probably some kind of managed cloud service.
- dickfickling 6y ago
  https://news.ycombinator.com/item?id=26888735 https://news.ycombinator.com/item?id=26888735
  - eloff 6y ago
    I see, their long term goal is to make and sell an enterprise data access layer / tooling on to of databases and data sources, like those used inside big tech companies to mediate developer access to data.
anticristi 6y ago
"The ORM saves us time working, but they don't save us time learning." Paraphrasing Joel Spolsky. Also, I hate every single time he is right, which at this point is daily.
matheusmoreira 6y ago
> 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.
- narrator 6y ago
  ORMs are great when you have to update large graphs of objects. They are not great for querying. The performance of querying is so unpredictable in an ORM that it's better to handle these read queries by hand. Things that tend to screw up performance are the N+1 query problem and generated SQL causing bad query plans. One needs to get to know one's database query planner in order to get the best performance, and that requires dealing with the raw SQL.
fabian2k 6y ago
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.
ckmar 6y ago
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 https://github.com/craigmichaelmartin/pure-orm
rendall 6y ago
I despise ORMs. I don't judge programmers very often, but invariably if there is an ORM, there is a fragile, tightly coupled, difficult-to-maintain project nearby
- jdc0589 6y ago
  currently staring at what's left in a large legacy rails/activerecord app figuring out what to do with. the suffering is real.
  - ysavir 6y ago
    What obstacles are you hitting?
    - jdc0589 6y ago
      the active record pattern, as it is commonly used, does not set you up well to lift individual components out of a monolith.
      - caspar 6y ago
        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-codebases-with-private-activerecord-models.html 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.
        jdc0589 6y ago
        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.

by eloff 6y ago

nawgz 6y ago

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

eloff 6y ago
> 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 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?

swyx 6y ago

to wit: how exactly does Prisma make money?

eloff 6y ago
I think they don't, yet. I'm sure they have a plan for that, probably some kind of managed cloud service.
dickfickling 6y ago
https://news.ycombinator.com/item?id=26888735 https://news.ycombinator.com/item?id=26888735
- eloff 6y ago
  I see, their long term goal is to make and sell an enterprise data access layer / tooling on to of databases and data sources, like those used inside big tech companies to mediate developer access to data.

anticristi 6y ago

"The ORM saves us time working, but they don't save us time learning." Paraphrasing Joel Spolsky. Also, I hate every single time he is right, which at this point is daily.

matheusmoreira 6y ago

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

narrator 6y ago
ORMs are great when you have to update large graphs of objects. They are not great for querying. The performance of querying is so unpredictable in an ORM that it's better to handle these read queries by hand. Things that tend to screw up performance are the N+1 query problem and generated SQL causing bad query plans. One needs to get to know one's database query planner in order to get the best performance, and that requires dealing with the raw SQL.

fabian2k 6y ago

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.

ckmar 6y ago

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 https://github.com/craigmichaelmartin/pure-orm

rendall 6y ago

I despise ORMs. I don't judge programmers very often, but invariably if there is an ORM, there is a fragile, tightly coupled, difficult-to-maintain project nearby

jdc0589 6y ago
currently staring at what's left in a large legacy rails/activerecord app figuring out what to do with. the suffering is real.
- ysavir 6y ago
  What obstacles are you hitting?
  - jdc0589 6y ago
    the active record pattern, as it is commonly used, does not set you up well to lift individual components out of a monolith.
    - caspar 6y ago
      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-codebases-with-private-activerecord-models.html 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.
      - jdc0589 6y ago
        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.