If you really do that, people tend to accuse you of doing RPC and not building a "true" API, because you're creating a lot of special case functions for the remote caller's business case.
> Product‐centric: GraphQL is unapologetically driven by the requirements of views and the front‐end engineers that write them. GraphQL starts with their way of thinking and requirements and builds the language and runtime necessary to enable that.
The whole point of GraphQL is that since each client asks for exactly the fields they want, having those "special case functions" is not a problem because other clients don't need to ask for those fields.
Doing the former leads to basically reimplementing SQL in GraphQL. Doing the latter leads to functions like `resolve_month_over_month_profit_and_loss_segemented_by_sector`.
Like every tool, there's a sweet spot where it really shines and others where it doesn't fit. If you need to have access to a bunch of disparate datasources it's really nice to have that layer of abstraction.