3 ms·
100%, it makes it easy for bad programmers to write bad performing queries, but you can easily write performant code. Btw that’s a feature - letting people ramp
by romafirst3 3y ago
100%, it makes it easy for bad programmers to write bad performing queries, but you can easily write performant code. Btw that’s a feature - letting people ramp up to full db knowledge is beneficial, you don’t want to be spending your time writing performant queries before you need to.
- topspin 3y ago> it makes it easy for bad programmers to write bad performing queries That is true of every ORM in existence. The easiest thing to do is naively follow the object graph in code, because that's what the ORM gives you. If the ORM was to somehow add friction here to encourage some other approach it would be panned as "too hard!!1" and fade away into obscurity.
- romafirst3 3y agothat is what I meant by saying it's a feature. It's easy to get started and do 99% of the stuff. When you are lucky enough to hit performance problems it's easy (for someone with knowledge) to fix your performance problems within the structure of Rails. It's awesome.
- topspin 3y ago> it's easy (for someone with knowledge) I don't think this is generally true. This sort of work has a lifecycle. By the time the performance problems emerge, often years later, the people involved that understood what is going on, and the tooling involved in building the system, are no longer readily at hand. This gets multiplied by the fact that often an N+1 problem is compounded by decoupling strategies (network APIs, etc.) where the front and backend must both be evolved: The backend needs a new, better API and the frontend has to adopt it. Often these are two completely distinct technology stacks, and also often spread among multiple parties which cannot easily coordinate change. Anything is possible, of course. But "easy" goes right out the window.