REST vs GraphQL vs gRPC

Post by pavel_lishin » Tue, Mar 16, 2021, 2:41 AM UTC

ec109685 wrote: post #45

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…

We solve the cacheability part by supporting aliases for queries by extended the GraphQL console to support saving a query with an alias. Also, with gzip, the size of json is not a big deal given redundant fields compress well.

Post by mkoubaa » Tue, Mar 16, 2021, 3:10 AM UTC

arethuza wrote: post #89

zedr wrote: post #75

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

You are quite correct, but by this stage the original definition of REST to include HATEOAS has pretty much been abandoned by most people. Edit: Pretty much every REST API I see these days explains how to construct your URLs to do different things - rather than treating all URLs as opaque. Mind you having tried to create 'pure' HATEOAS REST API I think I prefer the contemporary approach!

Post by robin21 » Tue, Mar 16, 2021, 9:18 AM UTC

nwienert wrote: post #123

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.

On the GraphQL side you can use gqless[0] (or the improved fork I helped sponsor, here[1]). It's by far the best DX I've had for any data fetching library: fully typed calls, no strings at all, no duplication of code or weird importing, no compiler, and it resolves the entire tree and creates a single fetch call. [0] https://github.com/gqless/gqless [1] https://github.com/PabloSzx/new_gqless

Post by robin21 » Tue, Mar 16, 2021, 9:23 AM UTC

bluejekyll wrote: post #42

Additional GraphQL con: it requires some thought and planning in order to ensure data is cacheable in CDNs and other reverse proxies. This is generally simpler in REST because the APIs tend to be more single use. In GraphQL you have to essentially predefine all the queries in order to achieve the same cache-ability of responses. Then identify those, essentially, over REST.

Post by mixxit » Tue, Mar 16, 2021, 10:14 AM UTC

malkia wrote: post #34

mixxit wrote: post #20

I wish gRPC was bidirectional For now I will stick to SignalR

It supports bidi, and also single request, multiple responses, or multiple requests, single response - https://grpc.io/docs/what-is-grpc/core-concepts/#bidirection...