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

81–90 of 168 posts

Re: REST vs GraphQL vs gRPC

#81

Post by lokar »

swyx wrote: post #60
sbayeta wrote: post #38

Earlier quoted context omitted.

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

Also, many others:

- Standard Authentication and identity (client and server) - Authorization support - Overload protection and flow control - Tracing - Standard logging - Request prioritization - Load balancing - Health checks and server status

Re: REST vs GraphQL vs gRPC

#82

Post by ericbarrett »

speedgoose wrote: post #71

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

I think your instinct to reach for the straightforward solution is good. gRPC has advantages, but it also comes with complexity since you have to bring all the tooling along. And the CPU burden of (de-)serializing JSON is a very different story than when Protobufs were developed in 2001.

Re: REST vs GraphQL vs gRPC

#83

Post by stickfigure »

No mention of what I see as the biggest con of GraphQL: You must build a lot of rate limiting and security logic, or your APIs are easily abused.

A naive GraphQL implementation makes it trivial to fetch giant swaths of your database. That's fine with a 100% trusted client, but if you're using this for a public API or web clients, you can easily be DOSed. Even accidentally!

Shopify's API is a pretty good example of the lengths you have to go to in order to harden a GraphQL API. It's ugly:

https://shopify.dev/concepts/about-apis/rate-limits

You have to limit not just number of calls, but quantity of data fetched. And pagination is gross, with `edges` and `node`. This is is straight from their examples:

    {
      shop {
        id
        name
      }
      products(first: 3) {
        edges {
          node {
            handle
          }
        }
      }
    }
Once you fetch a few layers of edges and nodes, queries become practically unreadable.

The more rigid fetching behavior of REST & gRPC provides more predictable performance and security behavior.

Re: REST vs GraphQL vs gRPC

#84

Post by jayd16 »

tlrobinson wrote: post #69
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 think the benefits of HTTP caching are often exaggerated, especially for APIs and single page applications. Often I’ll want much more control over caching and cache invalidation than what you can do with HTTP caching. I’d be interested to see an analysis of major websites usage of HTTP caching on non-static (i.e. not images, JS, etc) resources. I bet it’s pretty minimal.

You can put a RESTful response on S3 (or even stub a whole service) but AFAIK you can't do that for gRPC or GraphQL.

Re: REST vs GraphQL vs gRPC

#85

Post by throwaway4good »

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…

Personally I prefer to have explicit control over the caching mechanism rather than leaving it to network elements or browser caching.

That is explicity cache the information in your JavaScript frontend or have your backend explicitly cache. In that way it is easy to understand and your can also control what circumstances a cache is invalidated.

Re: REST vs GraphQL vs gRPC

#86

Post by atraac »

dtech wrote: post #29
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/

In C# one can have a decent documentation just based on a few attributes so you don't even have to write that much to have that schema available to your clients.

Re: REST vs GraphQL vs gRPC

#87

Post by throwaway4good »

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.

Just be clear - I am not suggesting JSON-RPC as there is no envelope and the name of the invoked procedure is in the HTTP request line.

For example:

   POST /api/listPosts HTTP/1.1
   { userId: "banana", fromDate: 2342342342, toDate: 2343242 }
Reponse:

   HTTP/1.1 200 OK
   [ { id: 32432, title: "Happy banana", userId: "banana" }, ... ]
Or in case of an error:

   HTTP/1.1 500 Internal Server Error
   { type: "class name of exception raised server side", message: "Out of bananas" }
The types can be specified with TypeScript needed.

Re: REST vs GraphQL vs gRPC

#88

Post by pietromenna »

bigmattystyles wrote: post #65
littlecranky67 wrote: post #47

Earlier quoted context omitted.

OData had its momentum but since a couple of years at least, there is no maintained JS odata library that is not buggy and fully usable in modern environments.

I can't disagree there, and for all the work MS is putting into it right now for it in dotnetcore - I don't understand how they can have this big a blind spot.

I agree with you that there is support for oData v2 and v4. But they are not exactly mainstream out there. I like oData v4 and I try to use it when it is opossible.

Re: REST vs GraphQL vs gRPC

#89

Post by arethuza »

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!

Re: REST vs GraphQL vs gRPC

#90

Post by mdavidn »

There are a variety of tricks to solve the over/under-fetching problems of REST. My default approach is JSON:API, which defines standard query parameters for clients to ask the server to return just a subset of fields or to return complete copies of referenced resources.

https://jsonapi.org/

Post reply on HN