For me GraphQL is the epitome (in the Web tier) of 'we need to solve the same problems as FAANG does'.

You'll likely never be in a situation where over-querying via a non-granular REST call will ever be an issue worth optimising around.

If you're shipping multi-megs of JS to a client don't then pretend that micro-optimisating the API call waterfall is your KPI, it's just disingenuous at best.

At best it's a band-aid around dysfunctional inter-team working.

> For me GraphQL is the epitome (in the Web tier) of 'we need to solve the same problems as FAANG does'.

I work at a small startup. We use a REST and Redux architecture. It's worked very well for us, but we're starting to hit some pain points. As we look to re-architect, our list of challenges pretty much mimic the challenges GraphQL looks to address. These aren't scaling issues or "big company issues". In my opinion, they're core issues with every client-server code base.

* Client Data and Statement Management

* API Coordination and Versioning (even more complex if you have a public API)

* Payload Management and Relational Data (it can be very expensive to pro-actively return embedded/dependent data, so you need to manage it somehow)

* Caching and De-deduping

* Typing and Data Interfaces between Client/Server

* Error Management (not that hard to standardize, but still something you need to account for)

* Pagination, Filtering, Sorting, etc.

There are issues that you get with GraphQL that are generally much easier to solve with REST, though. While it's easy to set up a GraphQL API that technically makes your whole graph available, going off of your default resolver functions alone is going to cause serious performance issues as soon as queries start to get more complex. The default behavior is basically n+1. To fix that, you have to do query introspection, which is significantly more complicated than just having a dedicated endpoint. Depending on your data sources & how easy it is to cache, this can be more or less of a problem.

This isn't to say that GraphQL is bad or anything, but there are definitely some gotchas that are important to evaluate before diving in.