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

11–20 of 168 posts

Re: REST vs GraphQL vs gRPC

#11

Post by [deleted] »

dboreham wrote: post #5
sneak wrote: post #4

One thing that people seem to gloss over when comparing these is that you also need to compare the serialization. gRPC using protobuf means you get actual typed data, whereas typing in JSON (used by the other two) is a mess (usually worked around by jamming anything ambiguous-in-javascript like floats, dates, times, et c into strings). If you're using typed languages on either the client or the server, having a seria…

> usually worked around by jamming anything ambiguous like floats, dates, times, et c into strings because nobody has ever done this with protobuf... btw what is the protobuf standard type for "date"?

[deleted]

Re: REST vs GraphQL vs gRPC

#12

Post by [deleted] »

throwaway4good wrote: post #10

Am I the only who simply does remote procedure calling over http(s) via JSON? Not REST as in resource modelling but simply sending a request serialized as a JSON object and getting a response back as a JSON object.

[deleted]

Re: REST vs GraphQL vs gRPC

#13

Post by teeray »

dboreham wrote: post #5
sneak wrote: post #4

One thing that people seem to gloss over when comparing these is that you also need to compare the serialization. gRPC using protobuf means you get actual typed data, whereas typing in JSON (used by the other two) is a mess (usually worked around by jamming anything ambiguous-in-javascript like floats, dates, times, et c into strings). If you're using typed languages on either the client or the server, having a seria…

> usually worked around by jamming anything ambiguous like floats, dates, times, et c into strings because nobody has ever done this with protobuf... btw what is the protobuf standard type for "date"?

That would be a Timestamp, found in the "well-known types" [0]. You can use your own encoding (milliseconds since epoch, RFC3339 string, etc), but using Timestamp gets you some auto-generated encoding / decoding functions in the supported languages.

[0] https://developers.google.com/protocol-buffers/docs/referenc...

Re: REST vs GraphQL vs gRPC

#15

Post by TeeWEE »

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.

Re: REST vs GraphQL vs gRPC

#16

Post by sneak »

throwaway4good wrote: post #10

Am I the only who simply does remote procedure calling over http(s) via JSON? Not REST as in resource modelling but simply sending a request serialized as a JSON object and getting a response back as a JSON object.

I've done JSON-RPC at scale before and the one downside to it is that you have to write a custom caching proxy for readonly calls that understands your API.

With REST you can just use a normal HTTP caching proxy for all the GETs under certain paths, off the shelf.

Using a hybrid (JSON-RPC for writes and authenticated reads, REST for global reads) would have saved me a lot of time spent building and maintaining a JSON-RPC caching layer.

There is benefit to a GET/POST split, and JSON-RPC forces even simple unauthenticated reads into a POST.

The other issue with JSON-RPC is, well, json. It's not the worst, but it's also not the best. json has no great canonicalization so if you want to do signed requests or responses you're going to end up putting a string of json (inner) into an key's value at some point. Doing that in protobuf seems less gross to me.

Re: REST vs GraphQL vs gRPC

#17

Post by danpalmer »

throwaway4good wrote: post #10

Am I the only who simply does remote procedure calling over http(s) via JSON? Not REST as in resource modelling but simply sending a request serialized as a JSON object and getting a response back as a JSON object.

This is fine at a small scale. When you're one dev or a small team you can understand the whole system and you'll benefit from this simplicity.

When you're many devs, many APIs, many resources, it really pays to have a consistent, well-defined way to do this. GraphQL is very close to what you've described, with some more defined standards. GRPC is close as well, except the serialisation format isn't JSON, it's something more optimised.

As a team grows these sorts of standards emerge from the first-pass versions anyway. These just happen to be pre-defined ones that work well with other things that you could choose to use if you wanted to.

Re: REST vs GraphQL vs gRPC

#18

Post by corytheboyd »

throwaway4good wrote: post #10

Am I the only who simply does remote procedure calling over http(s) via JSON? Not REST as in resource modelling but simply sending a request serialized as a JSON object and getting a response back as a JSON object.

No, I have seen many such approaches. It draws undue criticism when the actual REST API starts to suffer due to people getting lazy, at which point they lump the RPC style calls into the blame.

Re: REST vs GraphQL vs gRPC

#19

Post by hashkb »

sneak wrote: post #16
throwaway4good wrote: post #10

Am I the only who simply does remote procedure calling over http(s) via JSON? Not REST as in resource modelling but simply sending a request serialized as a JSON object and getting a response back as a JSON object.

I've done JSON-RPC at scale before and the one downside to it is that you have to write a custom caching proxy for readonly calls that understands your API. With REST you can just use a normal HTTP caching proxy for all the GETs under certain paths, off the shelf. Using a hybrid (JSON-RPC for writes and authenticated reads, REST for global reads) would have saved me a lot of time spent building and maintaining a JSON…

If I'm going to neuter HTTP like that, I at least do RPC over websockets for realtime feel. And I still usually run it through the whole Rails controller stack so I don't drive myself insane.
Post reply on HN