But … queries are *not* resources. And resource mutations and subscriptions are the *result* of processes, not processes themselves. I think it’s important to stay grounded in an ontological sense to what things really are.

I agree that gRPC is certainly a reasonable option for process invocation, but including it increases the complexity and weight of the stack overall. And its lack of browser support as much as its process orientation relegates it to the service layer. The initial client request that could be handled via gRPC still usually arrives via REST. Finally, gRPC *can* theoretically be much more performant than REST, but reactive processing models in REST services can also perform well, and I’ve seen gRPC implemented in libraries that have crippled its performance.

Overall, I see the question as “can I do the things I need to do with REST alone” with good performance and without unnecessarily complicating things? So far, the answer for me has been yes.

I still consider GraphQL to be a solution in search of a problem. Here again, a well-implemented caching mechanism (already part of most tech stacks) can provide most if not all of the benefits claimed by GraphQL without the additional weight and complexity.

Just my $0.02