The Chapter 1 of book “Craft GraphQL APIs in Elixir with Absinthe” explains this problem very well. You can read it.
In summary, it:
- allows the users of API (frontend developers, mobile app developers, etc.) to describe the data structure that they want, no more overfetching or underfetching:
- overfetching - downloading unnecessary data
- underfetching - a specific endpoint doesn’t provide enough of the required information. The client will have to make additional requests to fetch everything it needs
- allows the creators of API (backend developers) to focus on data relationships and business rules instead of implementing and optimizing specific endpoints:
- no more annoying user input validation
- no more limited flexibility of query parameters
- no more endpoints which are similiar but return different data
- …
GraphQL solves above problems. If you are facing these problems, consider to use it. Or, you don’t need it, maybe.
I think I’m right there with ya.
Still one of the best libraries I’ve used. The idea that every field in an API is backed by a function, and a query represents a sort of composition of them, is very easy for me to reason about.