Hacker News Reader

> Suppose your client wants to get all of a user's friends whose hometown is NYC. Even with http/2, it has to use the first API, wait for the response containing a list of userIDs, then use the second API to get all of their hometowns.

Not only that, but the resulting set will have inconsistencies if the database changes between the two requests. It's very unusual for HTTP applications to maintain transactional consistency over multiple requests.

This can be a security issue among other things, and even when it isn't, it can result in the display of glitchy data, whose inconsistency persists in the client which fetched them.

For example, you get all of the user's friends' userIDs. Then the DB is changed to remove one of the friends (by that friend). Then that friend changes their hometown to a new place, that they don't want the original user to know, and expects the original user can't see.

Then you do the second API call to get the hometowns of the userIDs. The result contains the new place that you should not have been able to access, and maybe it's shown on a screen for an unbounded time after that, or printed in a report.

Similar issues occur when fetching data to sum into totals and finding it doesn't match an expected total, or expecting some logical constraint to hold for every item in the result because it's implied by the original query.

(Live-streamed query updates turn these into momentary glitches, which is still wrong but at least those disappear from view soon after.)

> Then you do the second API call to get the hometowns of the userIDs. The result contains the new place that you should not have been able to access

This is an issue with access control, not HTTP requests. The second HTTP request shouldn't return information you don't have access to.

Not really, that's just an artifact of the example, which I constructed to emphasise that consistency errors can be serious.

But I agree that if access control were used (and pushed down to the database, rather than implemented on the client side), it would prevent that particular example from returning the disallowed data.

Even with access control the problem is still there. In the example but with database-level access control added as you suggest, the client gets an access error instead of a consistent resultset. Or missing data instead of a consistent resultset. In either case, the client needs extra code to handle the inconsistency caused by the sequence of dependent HTTP requests, or it will render an invalid screen. In some cases, maybe throw errors trying to render it because the data is in an "impossible" state that wasn't allowed by the database logic.

For example, a person without an address is shown, even though the database never contains a person without an address. Or nothing is shown, because of the access error, unless the client has "retry on access error" logic.

Try to imagine how unprofessional that would look if it was, say, a bank statement line without an amount.

These inconsistent data hazards can get complicated easily, as they arise from all sorts of weird corner cases that rarely arise and are hard to enumerate. Defensive programming is needed to handle them, and even then it can be hard to ensure every case is handled well. They are also hard to test.

This also ignores things like Hasura which does global optimization by converted GraphQL into a single SQL query.

Recently tried Hasura, big fan.

I think the Fields: header in the library is supposed to be used for that, it would look something like

   Fields: /users/*/hometown

in the same request.

It feels like it’s solving all the wrong problems to me - who actually wants to put varnish in between GraphQL client and server? Caching can be done more efficiently at either end. And this doesn’t provide a replacement for a query language, just moves some of the optimizations to the transport (http2) layer.

Now I’m wondering why Apollo doesn’t use http2 push to batch requests, instead of merging queries. Or does it?

Now all they need to do is allow the fields header to represent arbitrary graph structures and they will have reinvented GraphQL poorly.

Even directly accessing a database on localhost, your code will be slow if you send "select id from user where user.friend = ?" and then 1000 times "select town from address where user_id = ?" rather than one query with a join.

Why wouldn’t you return more data for the REST API instead of making dependent requests?

Because then 2 months later a dev refactors the front end to only require one of the fields, and suddenly you have the gorilla holding a banana and the whole jungle when all you asked for was a banana.

Yeah, it'd sure be nice if there was some way for the client to specify what data it wants.

I do that for my backends. On the HTTP request, the client sends a `?fields=encodeURIComponent(<JSON>)` query parameter to the server. If `fields` is present, then the API sends back the pruned version of the REST API. If `fields` is not present, then all the fields are sent back. Alternatively, you can prune the fields to a subset by default. The <JSON> looks like `{ foo=true, bar={baz=true}, bap=true} ` to imply the endpoint should send down field `foo`, nested object `bar` with only its field `baz` and the entire default nested object `bap`. I achieve this in Django Rest Framework by using meta-classes.

The people who write the API would need to know you want that data and implement the change, or write a new endpoint that returns the user details and the friends details in one request. With GraphQL the API wouldn't need to change; you'd just need to write the query on the frontend and it'd work.

For most web apps the overhead of adding a new endpoint is small so the benefit of GraphQL is also small, but if you're Facebook then GraphQL makes a huge amount of sense.

GraphQL is not a substitute for communication. You should be communicating your query patterns because all fields are not equal.

Because loading all the friends for a user needs to be done in five different places with slightly different data in each one, and loading the data for each request takes 500ms combined but only 150ms separately, plus there are specific questions about each friend like "is this friend in event X?" that only make sense if you know what X is, and when you add a parameter like event=X you notice that there's already an event parameter that does something else and all these different cases are becoming messy, your backend logic had started to reflect the frontend, and you wish you had some kind of way to query your graph of users to retrieve exactly the fields and embedded relationships you need.

see, this is where things like apollo client shine.

one part of the page makes a request and the rest of the page gets to use the data because now it’s in the local object cache.

I get what this article is saying but there is a lot more to graphQL than reducing network RT. It’s about replacing statically defined REST API responses.

As a prior commenter wrote, it’s making the backend more flexible when the front end devs change their mind.

GraphQL can support arbitrary numbers of fields and arbitrary nesting of relationships. You can do this:

    {
      hero {
        name
        friends {
          name 
            friends {
              name
            }
        }
      }
    }

But some clients might only need this:

    {
      hero {
        name
      }
    }

This is a small example, but it's pretty clear that "always including all fields and nested relationships in every REST API response" is not a viable solution.

(GraphQL examples based on the schema used in the official documentation: https://graphql.org/learn/queries/)

This is the most important comment in this thread. For more, read this excellent article:

https://brandur.org/graphql

At my previous job we had a method that became known as a "superset". It would fetch a record and all data related to that, and then a lot of other data related to that. It would return tens of MB of XML every time. It was huge, but so many services came to depend on it because it always had that piece of data someone needed.

All the data you needed was there, but every request caused a lot of memory usage and lots of database queries. GraphQL allows you to just ask for the fields you need without necessarily incurring the cost of returning anything else.

> Whereas with GraphQL, it facilitates building a single API call that says "give me all friends for a specific user, along with each friend's hometown".

Better yet, submit a request asking for all friends whose hometown is NYC (or whose hometown is the same as one of the user's previous hometowns, or...). That way only a subset of the data needs transmitting.

It's not really a valid argument, because if you only have two APIs and you can't create more, you can't switch to a GraphQL implementation in less time than you could add an appropriate endpoint.

  GET users/<id>/friends
       ?fields=friend.*
       &where=hometown:'NYC'
       &aggregate=distinct

http2 has push, so you can make a single request (for the friends of a user) and then just push all the users in that response before the client requests it. this all happens over a single connection and leverages all the http infrastructure and experience you already have