Well-implemented internal GraphQL APIs, and intelligent caching on the client, are a step in the right direction, separating query optimization from the data ne

Well-implemented internal GraphQL APIs, and intelligent caching on the client, are a step in the right direction, separating query optimization from the data needed by the view layer. (Though you could argue that this is wasting cycles to have that level of abstraction, but abstraction can be useful in its own right.) This is still ongoing work; for instance, see https://github.com/tfoxy/graphene-django-optimizer https://github.com/tfoxy/graphene-django-optimizer which is in progress as of two days ago, and attempts to do away with the N+1 problem systematically. But more generally, if you're worried about this, choose to work on projects whose impact on the world (however you want to define it) is greater than the electricity your servers use. And if you're working in that direction, your speed to market is much more important than your electricity cost, or your support of legacy hardware. Design abstractions (ORMs, APIs) so that they can be optimized in the future, imagine that they'll be rewritten at that point in Go or Rust by dedicated teams, but in the meantime, stay laser-focused on your vision. This applies whether you're at the smallish vNext team at Microsoft, or a startup nobody's heard about. It's "performance debt," and it's often the most efficient way to capitalize your initiative.