GraphQL is not about the server-side - that's an implementation detail and is orthogonal to GraphQL itself. I think it's important that we don't conflate ORMs with GraphQL just because an ORM can be used to simplify the server-side implementation (take a look at Graphene [1] or Prisma [2]).
[1] https://github.com/graphql-python/graphene [2] https://github.com/prismagraphql/prisma
And yet. Somebody has to be there to parse GraphQL and turn those queries into database or other external calls--and do so efficiently--for a large/combinatoric number of potential variations of entity graphs.
This is why we are going to surface the more complex children of certain models as root queries instead. It’s considerably less than ideal from an idiomatic GraphQL point of view, but it’s much more practical. If data models are simpler, then GraphQL works great. Or if the data model is flat, it works great. Anything else and it’s not as cut and dry.
That said, GraphQL-the-spec does highlight a key ORM weakness--it's not so easy to dynamically construct complex join queries with decently-optimized fetch plans.