Comment by headcanon | Hacker News Reader

Comment by headcanon | Hacker News Reader

Parent Full thread

Having used graphql in production environments for about 6 months now, I would say that it is amazing and should be a first option for new APIs. The big selling points for me are:

1) self-documenting and explorable API (via GraphiQL interface) mean I don't have to ask backend if this or that value has been put in there.

2) expensive-to-fetch attributes returned in a query are only fetched/calculated if asked for. This means we don't need to split off logically similar queries into two REST endpoints to optimize the site

3) strict type and value checking mean I will always get back what I expect to get back. Attributes can be deprecated and throw a warning if I ask for them. If I ask for an attribute that is outside the spec it will give me an error. This is great for code maintainability.

4) frontend and backend can communicate more effectively with a standard contract. Building a react frontend with Apollo made me constantly question why I was getting paid so much to do what I did, it was that easy.

5) Implementation specific, but Apollo is really amazing and handles caching, dependent queries (I can ask a set of queries to refetch if I perform an update), and is dead simple to create a frontend around.

I haven't played with graphql much yet but one thing that really struck me most was that it's possible for a single graphql query to make multiple queries to database. I read that dataloader helps in this case, is this similar to what you mentioned in #5?

#5 was just about client caching. Yes it is true a naive graphql implementation can make multiple db queries which can create a performance concern, but there are ways to mitigate it with various tools, or with clever structuring of the schema.

Its an artifact of being able to define an individual, independent resolver for each attribute. The advantage of this though is that it makes it easy to stitch together multiple data sources into one schema, so GraphQL shines especially as a wrapper, or as a query layer on top of a non-relational data store, like Mongo or Dynamo

Apollo client is great in many ways. Where I'm having trouble is as my React app grows I need to update the local cache when I add or delete items. You have to tell Apollo what to do and it becomes more complex as the app grows. Almost like you're mirroring your db on the client.

You could just always tell it to re-fetch, effectively disabling caching.

> Almost like you're mirroring your db on the client.

Well that was the goal of mini-mongo in Meteor, before they ramped down development to work on Apollo. I think mirroring the db on the client is sort of the goal.

Reply on news.ycombinator.com