All these patterns are helpful because theyre consistent. The graphql and grpc systems are “good” because theyre schema driven so that makes automated tooling easier. That being said, the problem at smaller scales doesnt really exist too much. Saving bytes on the wire is such a weird optimization at early to mid stages that - unless latency is your actual problem ends up being an optimization with very little business value.
REST vs GraphQL vs gRPC
51–60 of 168 posts
Re: REST vs GraphQL vs gRPC
#52The `versus` nature of this question was the driving force behind a project I built last year.
I've been in multiple shops where REST was the standard -- and while folks had interest in exploring GraphQL or gRPC, we could not justify pivoting away from REST to the larger team. Repeatedly faced with this `either-or`, I set out to build a generic app that would auto provision all 3 (specifically for data-access).
I posted in verbose detail about that project a few months ago, so here I'll just provide a summary: The project auto provisions REST, GraphQL & gRPC services that support CRUD operations to tables, views and materialized views of several popular databases (postgres, postgis, mysql, sqlite). The services support full CRUD (with validation), geoquery (bbox, radius, custom wkt polygon), complex_resources (aggregate & sub queries), middleware (access the query before db execution), permissions (table/view level CRUD configs), field redaction (enable query support -- without publication), schema migrations, auto generated openapi3/swagger docs, auto generated proto file.
I hope this helps anyone in a spot where this `versus` conversation pops up.
original promotional piece: https://news.ycombinator.com/item?id=25600934
docker implementation: https://github.com/sudowing/service-engine-template
youtube playlist: https://www.youtube.com/playlist?list=PLxiODQNSQfKOVmNZ1ZPXb...
Re: REST vs GraphQL vs gRPC
#53Earlier quoted context omitted.
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…
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.
Re: REST vs GraphQL vs gRPC
#54I've recently stumbled upon WebRPC https://github.com/webrpc/webrpc It solves gRPC's inability to work nicely with web browsers.
https://github.com/jsmouret/grpc-over-webrtc is another way to get into the browser.
It's nice that you don't have to do any translation. Just gRPC in/out of the browser.
Re: REST vs GraphQL vs gRPC
#55I 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.
> The flip side (IMHO, at least), is that simple build-chains are underrated.
Wow, yes! Yes!
IDLs represent substantial complexity, and complexity always needs to be justified. Plain, "optimistically-schema'd" ;) REST, or even just JSON-over-HTTP, should be your default choice.
Re: REST vs GraphQL vs gRPC
#56i 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
#57Another 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…
What popular languages aren't supported by GRPC?
Re: REST vs GraphQL vs gRPC
#58The `versus` nature of this question was the driving force behind a project I built last year. I've been in multiple shops where REST was the standard -- and while folks had interest in exploring GraphQL or gRPC, we could not justify pivoting away from REST to the larger team. Repeatedly faced with this `either-or`, I set out to build a generic app that would auto provision all 3 (specifically for data-access). I pos…
What conclusions did you come to?
Re: REST vs GraphQL vs gRPC
#59Highly recommend taking a look at the JSONAPI spec - https://jsonapi.org/ It directly addresses the cons mentioned in the article while retaining all the pros
Tried it. Definitely not ready yet, and the scope may be large enough that it won't ever get there. Also, many of its design choices are fundamentally in tension with statically typed languages.
I think you can probably formalize JSON API schemas in a useful way, but JSON API ain't it.
Re: REST vs GraphQL vs gRPC
#60This is really just a comparison of the basic wire format. Full RPC systems like gRPC are much more.
Could you please elaborate briefly? Thanks!
i think they are talking about how it is very standard for gRPC systems to generate server and client code that make it very easy to use. see this comment for more https://news.ycombinator.com/item?id=26466902