[chuckadams]

The entire point of graphql servers is that they're basically ORMs (or use an underlying ORM) that turn complex nesting into a single query's worth of joins. It won't beat hand-crafted sql from an expert, but if that's your preferred approach, debates on the relative merits of different query frameworks are all academic to you anyway.

[RVuRnvbM2e]

I've never seen this kind of graphql server implementation that can automatically boil down a complex nested query to sensible SQL. It sounds like the best of both worlds. Do you have links?

[chuckadams]

Symfony API Platform boils to ORM-generated SQL via Doctrine, which is verbose, but not overly clever. So the only link I could give you there would be to the Doctrine query builder docs (I won't subject you to API Platform's docs). I imagine a more sophisticated graphql dialect like what Prisma supports can generate some pretty gnarly sql, but that's ORMs for you. But exposing your data model directly through graphql is also not recommended, same with REST APIs (I can't claim the high ground, my biggest graphql project exposes models directly. The tradeoff was worth it in this case). So in the end you're writing custom controllers/resolvers anyway, and field resolvers are where graphql really starts to shine.

[hansonkd]

Typically libraries use a Dataloader + ORM to implement this which gets you pretty far, outside of that some libs like Strawberry with automatically optimize your queries for you if you return Django ORM Querysets.

Any query you were going to build and serve with Rest can be made with these two methods or even a raw dataloader and manual SQL string.

[discreteevent]

The inventors of GraphQL did not intend it to be mapped directly to a database.

"That would be one way to implement the system in a DB-centric way. However we believe that intermediate application code is pretty critical to any GraphQL implementation." [1]

"GraphQL is a client-server dance that needs server-side capabilities, not just CRUD semantics." [2]

[1] https://news.ycombinator.com/item?id=9879870

[2] https://news.ycombinator.com/item?id=14351800

[hansonkd]

The Language Libs like Strawberry implement what he is describing by intermediate application code. It doesn't map directly to a database.

GQL implementations don't map to the database but to application code.

[chuckadams]

Specifically, GQL implementations always map to a `resolve(source, args, context, info)` function (the names can be anything, the types are what matter). In that sense, you also get a standard server interface similar to wsgi/psgi/rack, but much more fine-grained (there can be a resolver for every field in the query).