4 ms·

Why GraphQL over standard REST/JSON for most applications? I'm still not convinced.

ppeetteerr 8y ago
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.
josephg 8y ago
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/ https://developer.github.com/v4/explorer/
bebop 8y ago
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.
tango12 8y ago
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.
ypolito 8y ago
The thing that put me off about GraphQL is all the vulnerabilities I found related to it on HackerOne [1] I don't feel comfortable using it and I'd rather stick with something simple/manageable like JSON. [1] https://hackerone.com/hacktivity?order_direction=DESC&order_field=popular&filter=type%3Apublic&querystring=graphql https://hackerone.com/hacktivity?order_direction=DESC&order_... BTW: can anybody explain why I got shadowbanned?
chrisco255 8y ago
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.
rglover 8y ago
I wrote a detailed answer to "why" here if that helps: https://cleverbeagle.com/blog/articles/yeah-but-why-understanding-graphql-and-how-it-fits-into-your-product-stack https://cleverbeagle.com/blog/articles/yeah-but-why-understa...
linkmotif 8y ago
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.
nikolasburk 8y ago
We wrote about this a while a ago on the Prisma blog: https://www.prisma.io/blog/top-5-reasons-to-use-graphql-b60cfa683511 https://www.prisma.io/blog/top-5-reasons-to-use-graphql-b60c...

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.

josephg 8y ago

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/ https://developer.github.com/v4/explorer/

bebop 8y ago

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.

tango12 8y ago

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.

ypolito 8y ago

The thing that put me off about GraphQL is all the vulnerabilities I found related to it on HackerOne [1] I don't feel comfortable using it and I'd rather stick with something simple/manageable like JSON. [1] https://hackerone.com/hacktivity?order_direction=DESC&order_field=popular&filter=type%3Apublic&querystring=graphql https://hackerone.com/hacktivity?order_direction=DESC&order_... BTW: can anybody explain why I got shadowbanned?

chrisco255 8y ago

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.

rglover 8y ago

I wrote a detailed answer to "why" here if that helps: https://cleverbeagle.com/blog/articles/yeah-but-why-understanding-graphql-and-how-it-fits-into-your-product-stack https://cleverbeagle.com/blog/articles/yeah-but-why-understa...

linkmotif 8y ago

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.

nikolasburk 8y ago

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