When you use something like Apollo + a graphQL backend it makes client-side code considerably easier to deal with. Think of how much front-end code is simply fetching data, storing it locally, and then creating components to render that data. With Apollo, you use declarative graphQL strings to state what data you need to render a view, and then it handles all the fetching/retry/cache/subscription logic for you. You're able to iterate quicker because you have less CRUD code to deal with.

Other benefits are that you don't need to write multiple endpoints to serve condensed responses, since the client declares exactly what data it needs in the request. So a mobile client that only needs a fraction of the data of a web client can get back exactly what it needs, and there's no need for the backend to create separate REST endpoints or params for managing that. It's part of the spec.

It prevents over / under fetching. Eg, on certain screen sizes you might show more or fewer fields. With GraphQL you can decide the fields you want in the client and explicitly request them. You can do this with REST by passing in a lot of extra query parameters, but it’s pretty awful. So most people end up either over fetching (getting more data from the server than they need and discarding some of it) or underfetching (get a list of IDs, then make a follow up request per ID). GraphQL solves that really nicely - the client requests what it wants, and the server answers it in a single response.

GraphQL is also typed, and has some really great developer tooling as a result. It’s usually really easy to learn about a data source by just exploring in graphiql with ctrl+space autocomplete. Eg, check out github’s API: https://developer.github.com/v4/explorer/

Biggest reason, IMHO: The frontend developer experience of using APIs that speak graphql is amazingly better. Less APIs to call, better client side magic for managing app state, better client side magic to codegen, autocomplete type experience for API calls in your IDE.

I do not use GraphQL, so I don't have a strong opinion here, but the answer is that there is no standard REST/JSON API. There is actually a GraphQL specification that can be used to introspect the features of the API. This may not be enough to convince, but I think the introspection of REST/JSON API's are usually not as good as GraphQL or even SOAP.

There are two clear advantages:

1) Clear types and structs that are shared between client and server means that both can generate models based on a common set of data specs

2) Clients can have some autonomy in what data they choose to fetch. This is easier said than done but models may be set up to allow joins on datasets for custom model trees and reduced payload size by limiting the fields returned.

I wrote a detailed answer to "why" here if that helps: https://cleverbeagle.com/blog/articles/yeah-but-why-understa...

Coupling your frontend and backend, with type checking, is incredible! I think the Relay compiler is amazing and I don't know what I'd do without it.

We wrote about this a while a ago on the Prisma blog: https://www.prisma.io/blog/top-5-reasons-to-use-graphql-b60c...