REST, gRPC, or GraphQL: Which Should You Use?

[@JoaoVictorFerreira-xx1rq]

Once I used Graphql with strawberry library to consume an array of large objects and the performance was horrible, multiple times slower than rest. With my small knowledge/experience with Graphql, I imagine it is better than rest only for BFF and small requests as you said.

[@gui.ferreira]

That's the problem. It's hard to get it right

[@Fikusiklol]

Im currently trying graphQL and it actually feels really hard to build and also amount of sugar and short cuts are insane. Just feels like im swimming against the tide. From my experience, which is low, graphQL is only good for BFF.

[@zikkrype]

gRPC and good developer experience? Configuring, maintaining gRPC is exactly opposite of development experience. As you mentioned “not human readable” can be one the definitions of bad developer experience

[@parabambara]

Right?! My experience exactly. Ok, it's performant, but also a pain in the bottom to setup and maintain. Protobuf syntax, binary serialization, client code generation. When you're targeting performance you usually sacrifice convenience. And deactivate user using REST? Easy-peasy if you are not hell-bent on RESTFUL. Even GET request can contain a body and IIRC there is nothing in the RFC against that. And if you want to follow RESTFUL it becomes a kind of mind exercise - you can treat user block as a resource that can be POSTed or DELETEd from user. It's all in your mind. Frameworks and design patterns primarily should be enhancing development, not hindering it.

[@zikkrype]

@@parabambara maintaining proto file is something. You really need to be wealthy company to benefit from spending expensive developers time to maintain and troubleshoot grpc in order to benefit in long perspective

[@gui.ferreira]

I mentioned the developer experience from the consumer perspective. With tooling in place, you have the generated clients that simplify a lot