
Apollo Client 2.5 for GraphQL Announced - saranshk
https://blog.apollographql.com/announcing-apollo-client-2-5-c12230cabbb7
======
oaxacaoaxaca
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.

~~~
matt-snider
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/)

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

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

