6 ms·

Apollo Client 2.5 for GraphQL Announced

73 points by saranshk 8y ago

marcrosoft 8y ago
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...
oaxacaoaxaca 8y ago
I have mixed feelings about Apollo and GraphQL in general. To go from mature backend frameworks with autogenerated REST APIs to manually writing a lot of boilerplate code just to get a _basic_ GraphQL API running is frustrating. Part of the blame goes to the marketing of GraphQL. For example, the tagline on graphql.org is "Describe your data | Ask for what you want | Get predictable results". That's all well and good, but it leaves out the large majority of the work you have to do. This describes the schema, the query, and the result; but what about all the resolver code you have to write? That's the painful part of the whole process, especially when you get to the point of writing field-level resolvers and integrating child objects (DataLoader, etc.). And then on the frontend, Apollo is preaching for us to write client-side queries AND client-side resolvers to fetch data that's _already in the cache_. All of this just to read, for example, a single primitive value? This is just too much.
- chrisco255 8y ago
  If you need an autogenerated GraphQL API, look into Prisma (https://www.prisma.io/ https://www.prisma.io/) or AppSync (https://aws.amazon.com/appsync/ https://aws.amazon.com/appsync/). You can still use Apollo as a client side solution for the above. The client side resolvers Apollo speaks about is for client-side data. This is if you optionally want to use the same patterns on the front end to manage your local state. But it's totally optional. You can use Apollo + Redux or Apollo + setState or Apollo + MobX or Apollo + useReducer or whatever.
- matt-snider 8y ago
  Take a look at postgraphile for an auto-generated GQL API based on introspection of Postgres Schemas. https://www.graphile.org/ https://www.graphile.org/
  - deleted 8y ago
    [deleted]
- linkmotif 8y ago
  I just discovered https://hasura.io/ https://hasura.io/ the other day. Generate rich GraphQL UI APIs backed by postgres

73 points by saranshk 8y ago

marcrosoft 8y ago

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

oaxacaoaxaca 8y ago

I have mixed feelings about Apollo and GraphQL in general. To go from mature backend frameworks with autogenerated REST APIs to manually writing a lot of boilerplate code just to get a _basic_ GraphQL API running is frustrating. Part of the blame goes to the marketing of GraphQL. For example, the tagline on graphql.org is "Describe your data | Ask for what you want | Get predictable results". That's all well and good, but it leaves out the large majority of the work you have to do. This describes the schema, the query, and the result; but what about all the resolver code you have to write? That's the painful part of the whole process, especially when you get to the point of writing field-level resolvers and integrating child objects (DataLoader, etc.). And then on the frontend, Apollo is preaching for us to write client-side queries AND client-side resolvers to fetch data that's _already in the cache_. All of this just to read, for example, a single primitive value? This is just too much.

chrisco255 8y ago
If you need an autogenerated GraphQL API, look into Prisma (https://www.prisma.io/ https://www.prisma.io/) or AppSync (https://aws.amazon.com/appsync/ https://aws.amazon.com/appsync/). You can still use Apollo as a client side solution for the above. The client side resolvers Apollo speaks about is for client-side data. This is if you optionally want to use the same patterns on the front end to manage your local state. But it's totally optional. You can use Apollo + Redux or Apollo + setState or Apollo + MobX or Apollo + useReducer or whatever.
matt-snider 8y ago
Take a look at postgraphile for an auto-generated GQL API based on introspection of Postgres Schemas. https://www.graphile.org/ https://www.graphile.org/
- deleted 8y ago
  [deleted]
linkmotif 8y ago
I just discovered https://hasura.io/ https://hasura.io/ the other day. Generate rich GraphQL UI APIs backed by postgres