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

21–30 of 168 posts

Re: REST vs GraphQL vs gRPC

#21

Post by hankchinaski »

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 slimmed down version of protocol buffer, it's self describing, cpu efficient and natively supported by the Go standard library and therefore probably a better option - although not as space efficient. If you talk with other non-Go services then a JSON or XML transport encoding will do the job too (JSON rpc).

The graphQL one is great as what is commonly known as 'backend for frontend' - but inside the backend. it makes the life of designing an easy to use (and supposedly more efficient) API easier (for the FE) but much less so for the backend, which warrants increased implementation complexity and maintenance.

the good old rest is admittedly not as flexible as rpc or graphql but does the job for simpler and smaller apis albeit I admit i see, anecdotally, it being used less and less

Re: REST vs GraphQL vs gRPC

#24

Post by mattwad »

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.

Not for me. I tried this with Javascript a couple years ago, and it was painful mapping to and from gRPC types everywhere. There's no "undefined" for example if you have a union type. You have to come up with a "EMPTY" value. On top of that, we had all kinds of weird networking issues that we just weren't ready to tackle the same way we could with good ol' HTTP.

Re: REST vs GraphQL vs gRPC

#25

Post by [deleted] »

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…

[deleted]

Re: REST vs GraphQL vs gRPC

#26

Post by omginternets »

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.

The flip side (IMHO, at least), is that simple build-chains are underrated.

As much as I love a well-designed IDL (I'm a Cap'n Proto user, myself), the first thing I reach for is ReST. It most cases, it's sufficient, and in all cases it keeps builds simple and dependencies few.

Re: REST vs GraphQL vs gRPC

#28

Post by codegladiator »

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.

Have you seen OpenAPI ? Generating client and server code in your programming language for rest/graphql/grpc is not new.

Re: REST vs GraphQL vs gRPC

#29

Post by dtech »

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.

There's solutions like that for GraphQL [1] and REST too. For REST OpenAPI/Swagger has a very large ecosystem, but does depend on the API author making one.

[1] https://graphql-code-generator.com/

Post reply on HN