Is GraphQL the Next Frontier for Web APIs?

I don't think this is actually true. I think you see some ideas plucked from Fielding's paper, but describing REST in terms of performing CRUD on resources is not what Fielding's paper is largely about. There's some good RESTful APIs out there, and Stripe does have a pretty nice API for the current state of API affairs. But I'd say we're still decently early in figuring out how to more widely leverage concepts from Fielding's paper, so declaring that REST isn't fulfilling needs seems a little short to me. I'd rather see what happens if more people commit to understanding & implementing other beneficial concepts in their APIs.

"REST also has other problems. Resource payloads can be quite large because they return everything instead of just what you need, and in many cases they don’t map well to the kind of information that clients actually want, forcing expensive N + 1 query situations."

So maybe the idea here is that it's harder to implement, but you can absolutely structure REST APIs to have these same benefits, and actually you may find it to offer benefits over graphql here. There is nothing un-REST-like about returning different message formats based on the client sending you a specified request header, or providing a url parameter, or what have you. You can actually leverage this to you (& your API client's benefit) by providing a small subset of different response "shapes", or you could just allow them to specify exactly what they need for a request in a free-for-all sort of fashion. It's all up to you, but I can't buy this argument for GraphQL, it's a symptom of writing inflexible REST-ish APIs, not a damning fact of REST as a concept.

So for example, if you allowed "comments" to be queried within a "user", you'd make sure that users could be looked up efficiently by their ID, and that comments could be loaded in bulk efficiently based on user ID. You'd also make sure that your implementation for both those operations is secure.

It's not too dissimilar to REST in that you're still very much designing what your API should look like and not exposing anything else.

The main power of GraphQL is for client developers and lies in the decoupling it provides between the client and server and the ability to fulfill the client needs in a single round trip. This is great for mobile devices with slower networks.

Introspection is a really powerful tool and you can build tools around that to do compile time checks and automatically generate class definitions based on your schema.

That sounds a lot more like a user profile resource than a user resource.

> But you also need a way to change their password. That's a different entrypoint.

Or, if you have a user resource rather than separate profile I and password resources, all partial updates could go to the same resource as PATCHes.

> Where does it go?

If you spend a lot of time thinking about that, you probably aren't doing REST.

> Is it a PUT or a POST?

Is it a replacement or a new resource? Largely, that depends on your domain model, and models under which either answer (or PATCH) make sense. As long as the definitions of your resource representations tell what operations are supported, and what they mean, for endpoints represented by the relevant link relations, it really doesn't matter all that much.

> The REST model tries to present a facade that everything is a "resource". In my experience, as apps get bigger, more and more things start not quite fitting that model.

I can't imagine how anything could fail to fit the model, unless you assume (as REST does not) that resources must be completely independent so that an action on one resource has no effects on the state of other resources.

The essence of the REST philosophy is to deal with data as small atomic building blocks - I think that this is one of the most important and well-tested ideas in software engineering so on that basis, I would go with REST. Though you could also argue that the idea of querying (which is what GraphQL essentially is) is also well tested.

CRDTs are bad with bandwidth and they require very heavy/complex clients that are difficult to implement - Once implemented, they make life easier for many use cases but take away flexibility and customizability.

I think the main challenge with GraphQL actually might be doing access control on the back-end. If you have a GraphQL query that fetches many different resource types, it's a lot more difficult to establish whether or not a user is allowed to access all these resources at once (GraphQL approach) vs just a single resource at a time (REST Approach).

With GraphQL you may have to deal with partial access rights - where the user is only allowed to see part of the query's result. With REST, each request can only have a single allowed/blocked response.