News for hackers. Stuff that matters.
Re:GraphQL Performance Monitoring Is Hard by true_religion on Saturday July 27, 2019 @05:12AM (#20541138)
REST works, but it forces you to use a single endpoint at a time.

For example, let's say you have have two endpoints /albums/1/ and /users/2/ and want to query them both at the same time.

They're unrelated data, so following REST best practices would make them separate endpoints.

With GraphQL, they're seperate resolvers but you can write

   {
     albums { get(id: 1) { .... } }
     users { get(id: 2) { .... } }
   }

And combine them those two calls into a single query. Maybe this is also possible via REST, but I haven't seen it.
Re:GraphQL Performance Monitoring Is Hard by toast0 on Saturday July 27, 2019 @10:30AM (#20542178)
If the endpoints are unrelated and you know them both before querying either, you can certainly query them concurrently from nearly any client language.

GraphQL can do it, but I don't think that's a big strength, compared to the dependent queries it can do. Using the results from one query to drive a further query without going back to the client will save a bunch of time if the client is far from the server.

Re:GraphQL Performance Monitoring Is Hard by true_religion on Saturday July 27, 2019 @01:58PM (#20543205)
Sure you can make two queries concurrently, but does the server know you are doing that? With GeaphQL the server sees both queries at once, and can potentially optimize over that once someone notices that in their logs. And it expresses itself as a single network connection.

I do agree though with your point about dependent queries, though I have only used GraphQL for internal apis so my experience doesn’t include that sort of problem.

Re:GraphQL Performance Monitoring Is Hard by Aeolun on Saturday July 27, 2019 @08:05AM (#20541625)
Oh! This is interesting. I didn’t know I could do this too. That’s a bit nicer even than only the combining of nested calls that I was aware of.