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

71–80 of 168 posts

Re: REST vs GraphQL vs gRPC

#71

Post by speedgoose »

> JSON objects are large and field names are repetitive

I used to write protocol buffer stuff for this reason. But I realized after some time that compressed json is almost as good if not better depending on the data, and a lot simpler and nicer to use. You can consider to pre-share a dictionary if you want to compress always the same tiny messages. Of course json + compression is a bit more cpu intensive than protocol buffers but it's not having an impact on anything in most use cases.

Re: REST vs GraphQL vs gRPC

#72

Post by sshb »

meowzero wrote: post #64
cogman10 wrote: post #57

Earlier quoted context omitted.

What popular languages aren't supported by GRPC?

Scala, Swift, Rust, C, etc. I guess with Scala you can probably use the Java one. But they have one for Kotlin...

Swift is at least supported via Objective-C, and swift-grpc looks solid https://github.com/grpc/grpc-swift

Re: REST vs GraphQL vs gRPC

#73

Post by karmakaze »

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.

Thrift supports many serializations both binary and human readable that you could choose at runtime, say for debugging.

I never did use the feature, having got tired of using Thrift for other reasons (e.g. poor interoperability Java/Scala).

Re: REST vs GraphQL vs gRPC

#74

Post by chills »

meowzero wrote: post #64
cogman10 wrote: post #57

Earlier quoted context omitted.

What popular languages aren't supported by GRPC?

Scala, Swift, Rust, C, etc. I guess with Scala you can probably use the Java one. But they have one for Kotlin...

Scala has several (approximately one per effect library): https://scalapb.github.io/docs/grpc/

Re: REST vs GraphQL vs gRPC

#75

Post by zedr »

> Easily discoverable data, e.g. user ID 3 would be at /users/3. All of the CRUD (Create Read Update Delete) operations below can be applied to this path

Strictly speaking, that's not what REST considers "easily discoverable data". That endpoint would need to have been discovered by navigating the resource tree, starting from the root resource.

Roy Fielding (author of the original REST dissertation): "A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). (...) Instead, allow servers to instruct clients on how to construct appropriate URIs, such as is done in HTML forms and URI templates, by defining those instructions within media types and link relations. [Failure here implies that clients are assuming a resource structure due to out-of band information, such as a domain-specific standard, which is the data-oriented equivalent to RPC’s functional coupling].

A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any client that might use the API). "[1]

1. https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...

Re: REST vs GraphQL vs gRPC

#76

Post by malkia »

jeffbee wrote: post #53
mattnewton wrote: post #40

Earlier quoted context omitted.

> 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…

Even if a process re-serializes a message, unknown fields will be preserved, if using the official protobuf libraries proto2 or 3.5 and later. Only in 3.0 did they drop unknown fields, which was complete lunacy. That decision was reverted for proto 3.5. Some of the APIs (C++ for example) provide methods to access unknown fields, in case they were only mostly unknown.

Oh, I see now - https://github.com/protocolbuffers/protobuf/releases/tag/v3.... (General) - I wasn't aware of that as I think I've started using proto3 after that version. Good to know.

Re: REST vs GraphQL vs gRPC

#77

Post by yeswecatan »

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.

My team has started doing this for workflow orchestration. When our workflows (implemented in Cadence) need to perform some complex business logic (grab data from 3 sources and munge, for example) we handle that with a RPC-style endpoint.

Re: REST vs GraphQL vs gRPC

#78

Post by meowzero »

chills wrote: post #74
meowzero wrote: post #64

Earlier quoted context omitted.

Scala, Swift, Rust, C, etc. I guess with Scala you can probably use the Java one. But they have one for Kotlin...

Scala has several (approximately one per effect library): https://scalapb.github.io/docs/grpc/

That's actually cool. It's been a while since I worked on GRPC with Scala. Back then we only had that thin wrapper around Java.

Re: REST vs GraphQL vs gRPC

#79

Post by thinkingkong »

phaedryx wrote: post #67
meowzero wrote: post #37

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 RE…

I believe that GraphQL handles this with "persisted queries." Basically, you ask the server to "run standard query 'queryname'." Since it is a standard, predefined query you can cache the results. Apollo support link: https://www.apollographql.com/docs/apollo-server/performance...

The browser supports built in caching without requiring a specific library; additionally the infrastructure of the web provides this as well.

Re: REST vs GraphQL vs gRPC

#80

Post by codegladiator »

rhacker wrote: post #62
meowzero wrote: post #37

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 RE…

Well actually, it can actually be more advanced with GraphQL. In fact GQL clients have the ability to invalidate caches if it knows the same ID has been deleted or edited and can in some cases even avoid a new fetch. That being said some of those advanced use cases may be off by default in Apollo.

How will the client know ?
Post reply on HN