Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

REST vs GraphQL vs gRPC

danhacks.com

Post reply on HN
Print view View original

31–40 of 168 posts

Re: REST vs GraphQL vs gRPC

#31

Post by lokar »

hankchinaski wrote: post #21

i don't know about you but in my experience, unless you have Google's size microservices and infrastructure gRPC (with protocol buffers) is just tedious. - need an extra step when doing protoc compilation of your models - cannot easily inspect and debug your messages across your infrastructure without a proper protobuf decoder/encoder If you only have Go microservices talking via RPC there is GOB encoding which is a…

I wish gRPC has the same ability as stubby (what google uses internally): logging rpc (calls and replies, full msg or just the hdr) to a binary file and a nice set of tools to decode and analyze them.

Re: REST vs GraphQL vs gRPC

#32

Post by sillyquiet »

In my opinion, it makes very little sense to compare GraphQL to REST from a client perspective - if you are only going to be hitting a single API endpoint, use REST (or gRPC I guess). The overhead of GraphQL doesn't make it worth using at that scale.

The strength and real benefit of GraphQL comes in when you have to assemble a UI from multiple data sources and reconcile that into a negotiable schema between the server and the client.

Re: REST vs GraphQL vs gRPC

#33

Post by adamkl »

TeeWEE wrote: post #15

I think for people who didnt try GRPC yet, this is for me the winner feature: "Generates client and server code in your programming language. This can save engineering time from writing service calling code" It saves around 30% development time on features with lots of API calls. And it grows better since there is a strict contract. Human readability is over-rated for API's.

Code generation and strong contracts are good (and C#/Java developers have been doing this forever with SOAP/XML), but they do place some serious restrictions on flexibility.

I’m not sure how gRPC handles this, but adding an additional field to a SOAP interface meant regenerating code across all the clients else they would fail at runtime while deserializing payloads.

A plus for GraphQL is that because each client request is a custom query, new fields added to the server have no impact on existing client code. Facebook famously said in one of their earlier talks on GraphQL that they didn’t version their API, and have never had a breaking change.

Really, I don’t gRPC and GraphQL should even be compared since they support radically different use cases.

Re: REST vs GraphQL vs gRPC

#35

Post by emodendroket »

TeeWEE wrote: post #15

I think for people who didnt try GRPC yet, this is for me the winner feature: "Generates client and server code in your programming language. This can save engineering time from writing service calling code" It saves around 30% development time on features with lots of API calls. And it grows better since there is a strict contract. Human readability is over-rated for API's.

So when are SOAP and WSDL coming back into Vogue?

Re: REST vs GraphQL vs gRPC

#37

Post by meowzero »

Another con of GraphQL (and probably GRPC) is caching. You basically get it for free with REST.

REST can also return protobufs, with content type application/x-protobuf. Heck, it can return any Content-Type. It doesn't have to be confined to JSON.

GRPC needs to support the language you're using. It does support a lot of the popular languages now. But most languages have some sort of http server or client to handle REST.

Re: REST vs GraphQL vs gRPC

#39

Post by jayd16 »

hankchinaski wrote: post #21

i don't know about you but in my experience, unless you have Google's size microservices and infrastructure gRPC (with protocol buffers) is just tedious. - need an extra step when doing protoc compilation of your models - cannot easily inspect and debug your messages across your infrastructure without a proper protobuf decoder/encoder If you only have Go microservices talking via RPC there is GOB encoding which is a…

> unless you have Google's size microservices and infrastructure

The protobuf stuff can start to pay off as early as when you have two or more languages in the project.

Re: REST vs GraphQL vs gRPC

#40

Post by mattnewton »

adamkl wrote: post #33
TeeWEE wrote: post #15

I think for people who didnt try GRPC yet, this is for me the winner feature: "Generates client and server code in your programming language. This can save engineering time from writing service calling code" It saves around 30% development time on features with lots of API calls. And it grows better since there is a strict contract. Human readability is over-rated for API's.

Code generation and strong contracts are good (and C#/Java developers have been doing this forever with SOAP/XML), but they do place some serious restrictions on flexibility. I’m not sure how gRPC handles this, but adding an additional field to a SOAP interface meant regenerating code across all the clients else they would fail at runtime while deserializing payloads. A plus for GraphQL is that because each client re…

> I’m not sure how gRPC handles this, but adding an additional field to a SOAP interface meant regenerating code across all the clients else they would fail at runtime while deserializing payloads.

This is basically the reason every field in proto2 will be marked optional and proto3 is “optional” by default. IIRC the spec will just ignore these fields if they aren’t set or if they are present but it doesn’t know how to use them (but won’t delete them, if it needs to be forwarded. Of course this only works if you don’t reserialize it. Edit: this is not true see below).

Post reply on HN