[hardwaresofton]

I do agree that GraphQL has improved developer experience, or at the very least improved the perceived experience (which is essentially the same as actually improving the experience). I cannot deny it's popularity, and that comes from hype along with usefulness (perceived or actual).

> Tools like GraphiQL make exploring APIs a pleasure.

This is an innovation of the developers of GraphiQL, not of GraphQL itself. It's possible to build IDE support similar ot that of GraphiQL, with the rich metadata and schema data that is available by design in OpenAPI + JSONSchema + JSON-LD + HATEOAS land. The problem is that no one did/was excited enough to, the slog from Swagger2 to OpenAPI3 might have sapped the enthusiasm of the community just enough (or the emergence of GraphQL), but it's not that the tools isn't possible with other approaches.

> There is also the nice addition of strict typing and there are libraries that automatically generate TypeScript types for you from the schema and/or your operations.

This was already present with OpenAPI and related tools, so I personally don't put this as something that GraphQL brought about.

[serverholic]

I don't want to piece together 4 different technologies to get the same thing.

And it's not even the same thing. You keep mentioning HATEOAS but that doesn't accomplish the same things as graphql at all. With HATEOAS I need to send out multiple requests to collect the data I need. With graphql I can send out one request to retrieve exactly the data I need. I can also combine multiple requests into a single request. GraphQL also only retrieves the fields you need by default. This is something you'd need to build manually with REST.

And yes, reducing the number of server requests does matter when you're trying to optimize for the largest market possible. Including people on slow mobile network connections where every request adds significant overhead.

[hardwaresofton]

> I don't want to piece together 4 different technologies to get the same thing.

> And it's not even the same thing. You keep mentioning HATEOAS but that doesn't accomplish the same things as graphql at all. With HATEOAS I need to send out multiple requests to collect the data I need. With graphql I can send out one request to retrieve exactly the data I need. I can also combine multiple requests into a single request. GraphQL also only retrieves the fields you need by default. This is something you'd need to build manually with REST.

All of this is reasonable, but my point was that we've abandoned a more flexible method, that had composable functionality and agreed-upon standards for GraphQL. You gained some pipelining, and some vertical filtering, but threw out a lot with the bathwater.

GraphQL does give you a way to do these things, and this is why it is popular (or at least a good reason why), but it is missing the wider possibilities of the other ecosystem. As people start to try and abstract over it they will be abstracting over a less robust, considered, standardized base.

> And yes, reducing the number of server requests does matter when you're trying to optimize for the largest market possible. Including people on slow mobile network connections where every request adds significant overhead.

Reducing the number of server requests does indeed matter -- I did not mean to propose it doesn't, reducing request was somewhat solved before now with the backend-for-frontend approach. There are lots of approaches to help people on slow mobile network connections, but the ultimate one is to server-render and trim as much as possible -- I'm not sure GraphQL is much better at this than REST with efficient endpoint choice.

[serverholic]

> You gained some pipelining, and some vertical filtering, but threw out a lot with the bathwater.

What are we missing that actually matters in practice? And yes, if you minimize the problems that graphql was built to solve it seems like a worse solution.

> As people start to try and abstract over it they will be abstracting over a less robust, considered, standardized base.

Facebook, a company who's apps serve billions of people came up with graphql to solve real problems. Saying it isn't well considered is asinine. As for standardization, last time I checked GraphQL has a spec and the GraphQL Foundation is a member of the Linux Foundation.

Again, what problems are you talking about that graphql doesn't solve? I mean actual, practical problems.

> reducing request was somewhat solved before now with the backend-for-frontend approach.

So now I need to write a backend for each use-case. That sounds better. Or I need to make my endpoints extra configurable which starts to approach graphql territory.

> the ultimate one is to server-render and trim as much as possible

Again, we're now entering the "why graphql was invented" territory. Sure I could add these to my REST endpoints.. OR I could write one graphql endpoint and get all of these.

[hardwaresofton]

> What are we missing that actually matters in practice? And yes, if you minimize the problems that graphql was built to solve it seems like a worse solution. > Again, what problems are you talking about that graphql doesn't solve? I mean actual, practical problems.

If you're using GraphQL and feel that it solves all your problems and isn't painting you into a corner, you are free to continue to use it and reap the efficiency rewards. I'm not here to convert you to REST or any other RPC methodology. One of the things that was lost with adopting GraphQL is partial responses -- being able to send part of the answer back before the entire request is complete. I'm not sure exactly what streaming looks like in GraphQL but do they have anything as simple and useful as SSE?

> Facebook, a company who's apps serve billions of people came up with graphql to solve real problems. Saying it isn't well considered is asinine. As for standardization, last time I checked GraphQL has a spec and the GraphQL Foundation is a member of the Linux Foundation.

I did not mean to imply that GraphQL was not considered -- just that it is less considered than the alternatives that existed, and certainly was less battle tested. Just because something has a spec does not mean the spec is good and well reviewed (though again, I'm sure GraphQL's has been looked at by smart people for large periods of time). I don't know what to make of the GraphQL Foundation being a member of the Linux Foundation,

> So now I need to write a backend for each use-case. That sounds better. Or I need to make my endpoints extra configurable which starts to approach graphql territory.

It's not that writing robust endpoints is approaching GraphQL territory, it's that GraphQL territory is bootstrapping robust endpoints for you, but it also locks you in to it's way of viewing the world. I prefer to use interoperable smaller tools rather than doing this, and maybe I'm losing out because of that, but I'd take the complexity of one or two or five robust endpoints over adoption of the entire GraphQL spec & ecosystem for what I'd consider minimal gain. To each their own.

> Again, we're now entering the "why graphql was invented" territory. Sure I could add these to my REST endpoints.. OR I could write one graphql endpoint and get all of these.

No, that was me pointing out that if you're trying to help low bandwidth clients, that's how you definitively do it, GraphQL is not the right solution in that case -- you try your best not to make any calls on the frontend at all, so it seems the point is moot there.

[htormey]

Also it can potentially reduce the client side logic needed to stitch said 4 requests together.

This can be a big complexity/bug preventer for multi client Apps (web, mobile, desktop).