Hacker News Reader

Comment by itake | Hacker News Reader

I don’t see the value ins Graphql. Most apis rarely change and the complexity of supporting queries is not worth the time saved.

Graphql was a cool experiment, but I’m sticking with rest/protobufs

View on HN

The original motivation was to reduce the number of network requests made on cellular network-connected mobile devices, both to save on power consumption and reduce latency for the user. It off-loads a lot of complexity and computation from the client to the server, and make sense if want to create as good a mobile experience as you can.

In terms of code architecture, it drastically simplifies frontend code, and overall reduces backend code and boilerplate. It's extremely elegant and nice to use over creating custom endpoints for every use-case, but the N+1 SQL query problem is a giant thorn.

You can still design an immutable REST api to match the client's needs. Apollo has really nice out-of-the-box caching that can be tricky to replicate with rest.

I see your point about reducing network requests (graphql lets you co-mingle mutations and queries), but I don't think that feature is used often enough, b/c what if one query fails, then everyone has to fail).

You can make a REST endpoint match a client's needs, but if you have multiple clients (for example, 1 for mobile and 1 for desktop) that all need different amounts of data (for example, the mobile client shows a simplified view with less data), then you would need to write 2 different REST endpoints to handle each clients. Multiply that by the number of pages with a difference.

> then you would need to write 2 different REST endpoints to handle each clients.

Or you use Accept header for its intended purpose

Accept: com.company.user-aggregated/json

Accept: com.company.user-aggregated-lite/json

etc.

And let the server return the fields defined by the relevant schemas.

I mean, the advise given for GraphQL in prod is to literally call predefined queries only.

> Apollo has really nice out-of-the-box caching that can be tricky to replicate with rest.

Caching is trivial to do with REST.

The "really nice caching" that Apollo does literally deserializes and deep inspects both the request and the response to try and figure out caching on specific fields. Also, POST requests are not cacheable according to HTTP spec.

With REST you set an ETag and/or Cache-Control headers and let your existing infra and client browsers handle that.

Kinda, by all accounts the original motivation was to solve the proliferation of endpoints. Everyone was already writing per-screen endpoints to solve the network requests problem (which, contrary to what many believe, wasn't magically solve by http2), but they were doing it in a way which played out in several ways:

1. Having to make a new endpoint every time your frontend changes

2. Not making a new endpoint, and just augmenting the existing one for a screen. Which would cause them to accumulate dead data over time (especially if multiple app versions had to be supported concurrently -- in the case of Facebook this was ~3000 versions).

3. Being lazy and finding a similar endpoint meant for another use case and piggy-backing it for your new usage.

All of these would create maintenance and organisational problems.

GraphQL is essentially a system that lets you write endpoint specs (in the form of GraphQL query documents) that the backend knows how to support. It's not a free lunch, you still have to do a lot of work on the backend to allow it to do this efficiently and securely (nowhere near as difficult as people make it out to be though), but it does a really good job at solving the endpoint maintenance problem.

> but the N+1 SQL query problem is a giant thorn.

It's worse because in a big system this becomes N+1 API calls to other systems (each with their own permissions, latencies, caching etc.)

> It's extremely elegant and nice to use over creating custom endpoints for every use-case, but the N+1 SQL query problem is a giant thorn.

Having not used, but only read about graphql, this was the first thing that struck me. It seems great at minimizing data transferred to the client, but it doesn't (seem to) stop that data being fetched from the DB - it just post-filters it.

I'm imagining a scenario like a dashboard, where you're getting a small amount of data from a lot of places. With REST, we'd generally do that by having a dedicated endpoint for the whole dashboard that executes a single query, letting the DB do what it's good at (efficiently retrieving required data). My naive impression is that graphql would execute a bunch of queries, trim what's not needed and join it all together. With anything non-trivial that seems like a performance nightmare.

For an API that centers around filters and nested subfilters to retrieve exponentially specific data, graphql can end up saving you a lot of work.

For anything else, it seems pointless.

Reply on news.ycombinator.com