[hn_throwaway_99]

That is exactly what GraphQL is designed to do. Taken straight from the spec:

> 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.

[dismantlethesun]

I was speaking of higher-level abstractions than that. For instance, do you have your API allow all possible arbitrary aggregations for your data or do you only special case the 3 or 4 that are pertinent to your business model?

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`.

[brunoc]

There can be a lot in-between here. You might end up with something like `Report(type: PROFIT_AND_LOSS, unit: MONTHLY, segment: 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.