Our journey in dropping the ORM in Go
alanilling.medium.com
Our journey in dropping the ORM in Go
1–10 of 157 posts
Re: Our journey in dropping the ORM in Go
#2I feel like the biggest problem with an ORM is how people try and use them. It’s like an all or nothing approach. You hit a wall where using an ORM for that sucks and so now using an ORM for everything sucks.
I never would have thought of using an ORM in golang, it doesn’t seem like that kind of language. Even an ORM in python is debatable.
Re: Our journey in dropping the ORM in Go
#3So frustrating. You got like 80% of the way there, and then went "nope, too much work" and diverted to add more complexity.
The answer is to write the SQL yourself, and the scan methods yourself. Code generation is better than ORM, but still a wrapper, still adds complexity, and still brings problems.
Yes it's a pain in the arse to write all that boilerplate in one go (pun intended). But if you'd started without an ORM you'd have written them one at a time as you needed them and barely noticed it.
Keeping your code aligned with your database schema is very little effort - database schema changes are usually rare and significant.
I write a view for each access method (so I can change the schema without worrying about changing every access method), and a function for each update/insert/delete (for the same reasons). It takes maybe 20 mins to write the whole set each time I have to add a feature with new data, which is a rounding error in the time it takes to write all the rest of it.
The point is that the database schema is optimised to storing data in the best way possible. The middle layer is optimised for processing data in the best way possible, and the front end is optimised for displaying data in the best way possible. None of these three things are equal. Use an interface between each of them. The interface is important and needs to be carefully considered.
Re: Our journey in dropping the ORM in Go
#4In NodeJS Prisma is really good for just building statically typed CRUD-like queries. It gives you result types inferred from the schema so you're less likely to make mistakes.
Would still use real SQL for serious stuff, but in my experience most queries are CRUD anyway so I don't see lightweight ORMs as a problem as long as they're not doing magic caching in the background and lazy fetching. Let me decide how I want to do that.
Re: Our journey in dropping the ORM in Go
#5Never understood the hate for ORMs. I need to map from my data storage to my domain model somehow, why write all that code myself
Re: Our journey in dropping the ORM in Go
#6So frustrating. You got like 80% of the way there, and then went "nope, too much work" and diverted to add more complexity. The answer is to write the SQL yourself, and the scan methods yourself. Code generation is better than ORM, but still a wrapper, still adds complexity, and still brings problems. Yes it's a pain in the arse to write all that boilerplate in one go (pun intended). But if you'd started without an O…
> I write a view for each access method (so I can change the schema without worrying about changing every access method), and a function for each update/insert/delete (for the same reasons).
Database view and stored procedures?
Re: Our journey in dropping the ORM in Go
#7i thought we'd all agreed 15 yrs ago to not use vietnam analogy to discuss orms.
Re: Our journey in dropping the ORM in Go
#8So frustrating. You got like 80% of the way there, and then went "nope, too much work" and diverted to add more complexity. The answer is to write the SQL yourself, and the scan methods yourself. Code generation is better than ORM, but still a wrapper, still adds complexity, and still brings problems. Yes it's a pain in the arse to write all that boilerplate in one go (pun intended). But if you'd started without an O…
What if there are no layers and you can’t think outside hierarchy?
There’s no reason for anyone else to take your view as sacrosanct since many many many apps and services are working just fine without ORMs.
You might accomplish something interesting today if you set aside protecting unimportant ephemera you talked yourself into believing.
Re: Our journey in dropping the ORM in Go
#9Never understood the hate for ORMs. I need to map from my data storage to my domain model somehow, why write all that code myself
Because relational databases are very good at (surprise!) relations. So in SQL you can query data from several joined tables, query only certain columns, aggregate columns etc. etc. And all of these things are made needlessly complicated by using ORM. Even with the best ORM, you still have to learn an arcane new syntax for stuff you could write in 30 seconds when using SQL...
Re: Our journey in dropping the ORM in Go
#10i thought we'd all agreed 15 yrs ago to not use vietnam analogy to discuss orms.
We have a new, shiny Afghanistan analogy to use!