[exogen]

> I cannot see any positive outcomes to adopting graphql

How about one HTTP request often being faster than multiple requests? How about only retrieving the payload you requested rather than all the extra data the API developers decided to expose in the endpoint – bandwidth isn't free? How about not having to add new custom bespoke API endpoints because some new part of the website just needs a few little different pieces of data that would normally require several round trips, pretty please? These are just normal everyday issues that people put up with when using REST APIs.

> A problem we can solve elegantly with HTTP/2 push using nearly identical underlying API servicing models. What's great about that approach is that it's totally transparent to the client; they just get better performance with less resources.

Shouldn't you use push when you know the client will ask for the resources? How would you know whether the client will ask for certain connected objects in this case? Would you just always be pushing every connected object over the wire?

I don't really see why you're giving such special distinction to one HTTP request vs. multiple HTTP requests. That is an arbitrary distinction to make. You shouldn't be asking "how much strain can a client put on my server with a single request? but oh, they can make multiple requests…" but "how much strain is a client going to put on my server to get all the data they need, whether it happens across one request or multiple?"

[KirinDave]

> How about one HTTP request often being faster than multiple requests?

Http/2 push.

But also: would it actually be more dev hours to write out the custom RESTful queries? If you're whitelisting individual queries. What's the difference then? You've just got a more awkward, uncachable, less split-routable protocol for exactly the same data.

> Shouldn't you use push when you know the client will ask for the resources?

Yes. If I know they intend to join data in, I can push it. I can even do this somewhat speculatively based on statistical patterns in clients. I can tune those values based on real data which can be refined over time.

[exogen]

> Yes. If I know they intend to join data in, I can push it.

Right, so if you don't have the full "query", which you don't with multiple REST round-trips, then you won't push it...

> I can even do this somewhat speculatively based on statistical patterns in clients. I can tune those values based on real data which can be refined over time.

Cool, so guessing. That's exactly what I want my API's performance profile to be based on. Sounds like a lot of work man, why don't you just use GraphQL instead? ;)

[KirinDave]

> Right, so if you don't have the full "query", which you don't with multiple REST round-trips, then you won't push it... well.

Yes. But of course, GraphQL ad hoc extensions are discussing limiting this arbitrarily as well.

> Cool, so guessing. That's exactly what I want my API's performance profile to be based on.

No. For example, if I can say that a banking customer wants to see a second page of transactions 90% of the time, then I should push the next page every time. If I can say they want to see the third page of transactions 10% of the time, then it makes sense to defer the cost.

[andrewingram]

Once your build pipeline is setup, there's no development overhead to whitelisting queries.

[KirinDave]

I don't actually even see the real engineering challenge of whitisting queries, outside of documentation and communicating errors.

It just because a confusing and unhelpful protocol choice if you start whitelisting queries. Without the "query" part it's just a DSL for graph retreival.

Why not put that client side if it is so expressive.