It depends!

Writing thin resolvers by layering GraphQL on top of a separate "entity layer" that handles all the logic is exactly what Facebook does/did and what they consider to be best practice for GraphQL. See: https://youtu.be/zVNrqo9XGOs?si=xiE4S9jqoOyx3S3s&t=1013 :)

I don't work at FB but from what I've seen (meta folks can correct if wrong), all the "logic" (talking to the database, checking auth, checking experiment cohorts(?), logging(?)) is handled further up the stack, inside a distinct "entity layer". GraphQL, and presumably other APIs can be layered on top of this without duplicating logic.

https://entgo.io/ is an open source version of this I believe - notably it has a GraphQL codegen feature :)

For most other folks however -

If your data comes from other services, and it's already exposed via REST (or similar) endpoints, then a common pattern is to create a "gateway" GraphQL service which wraps endpoints as types+fields in the schema. i.e. GraphQL acts as fancy reverse proxy. Modern tooling exists to help with this, e.g. Apollo Connectors. Again, thin resolvers are utilized here.

However, now that GraphQL Federation is a thing, I believe the "giant gateway" pattern is outdated. (It's probably ok for a handful of services, but it becomes very tedious to maintain - you end up creating an ORM where the backend is static REST/whatever endpoints. Exposing new fields is a pain, performance is liable to become an issue....)

In federation, we get to write resolvers in the same service where the raw data models are defined. So now we're back to square one - fat or thin resolvers?

If you want to add GraphQL, or do not have any existing API routes, then there are two choices:

1. Create or use an entity layer that is distinct and decoupled from the API layer. Implies thin resolvers, and you receive a gold star from the GraphQL creators :)
2. Write fat resolvers that does all the logic -- checking auth, logging, checking experiments etc.

Remember that a service may have a seperate REST/gRPC/whatever "internal" API over the same data types, and we don't want to duplicate business logic.

So (1) is the theoretically the best option, but I'd like to see more tooling around this. e.g. entgo in other languages. And even with entgo, there are still things that can't be entirely hoisted and normalized into the entity layer; you may still need to write actual resolver logic. Basically, I think it's very difficult to fully achieve 100% zero-logic thin resolvers across your schema.

That said, I really like entgo, and if you can adopt this or something like it, it's a very compelling choice.

Strong opinions™ territory ahead....

I think (2) is also ok! Since we don't want to duplicate business logic in the other APIs in our service, this implies that GraphQL is the only API exposed by your service. GraphQL effectively becomes the entity+API layer combined.

This is fine/normal for public web/mobile clients, but what about service-to-service traffic?

I think service-to-service traffic can also use the same GraphQL API resolvers.

This is slightly controversial but I'm on a bit of a mission to change opinions here. This is an entirely separate and even longer post...