Hacker News Reader

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

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

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

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.

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

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

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.

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

currently staring at what's left in a large legacy rails/activerecord app figuring out what to do with. the suffering is real.

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.

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.

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.

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

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.