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

141–150 of 168 posts

Re: REST vs GraphQL vs gRPC

#141

Post by ledauphin »

sagichmal wrote: post #61
ledauphin wrote: post #41

a big thing not called out here that both gRPC and GraphQL natively do, but that REST does not natively do, is schema definition for the payloads. It's massively useful to know exactly what 'type' a received payload is, as well as to get built-in, zero-boilerplate feedback if the payload you construct is invalid.

Sure, but that utility also carries massive costs: the infrastructure and tooling required to work with those schema definitions, especially as they change over time. It's certainly not the case that the benefits always, or even usually, outweigh those costs.

I disagree that tooling is required to work with them in the GraphQL case - you still end up getting and sending JSON in the vast majority of cases.

With gRPC you're absolutely correct. Then again, I wasn't trying to make an argument for or against any of these technologies per se - just pointing out that this is a major part of the value provided that wasn't really called out in the article.

Re: REST vs GraphQL vs gRPC

#142

Post by jayd16 »

treis wrote: post #140
jayd16 wrote: post #39

Earlier quoted context omitted.

> unless you have Google's size microservices and infrastructure The protobuf stuff can start to pay off as early as when you have two or more languages in the project.

Don't you get the same benefit by writing a Swagger spec?

Possibly. I don't usually find restful api gen to be quite as seamless. Value judgements aside, yes, you _could_ generate from swagger but with gRPC its built in and consistent.

Re: REST vs GraphQL vs gRPC

#143

Post by Aeolun »

QuinnWilton wrote: post #124
stickfigure wrote: post #83

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

I'm a huge fan of GraphQL, and work full-time on a security scanner for GraphQL APIs, but denial of service is a huge (but easily mitigated) risk of GraphQL APIs, simply because of the lack of education and resources surrounding the topic. One fairly interesting denial of service vector that I've found on nearly every API I've scanned has to do with error messages. Many APIs don't bound the number of error messages t…

I kind of feel that the server itself should protect against attacks like that. Of course it isn’t inherent in the specification, but I don’t think it’s something that an implementer should have to think about either (beyond, ‘have I enabled DOS mitigation ‘ anyway)

Re: REST vs GraphQL vs gRPC

#144

Post by Aeolun »

andrewingram wrote: post #126
stevebmark wrote: post #101

Earlier quoted context omitted.

edges and node come from Relay, not from the core GraphQL spec. They're just one way to do pagination. I like edges and node, it gives you a place to encode information about the relationship between the two objects, if you want to. And if all your endpoints standardize on this Relay pagination, you get standard cursor/offset fetching, along with the option to add relationship metadata in the future if you want, with…

Technically the spec is part of GraphQL itself now, but an optional recommendation, not something you’re obliged to do. That said, like you I am a fan. It’s a pretty defensible pattern, more here for those interested: https://andrewingram.net/posts/demystifying-graphql-connecti... The overall verbosity of a GraphQL queue tends to not be a huge issue either, because in practice individual components are only concernin…

Also by people that have heard of relay but already have an existing codebase. It’s not something that’s very simple to adopt out of hand.

Re: REST vs GraphQL vs gRPC

#145

Post by vladsanchez »

emodendroket wrote: post #35
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.

So when are SOAP and WSDL coming back into Vogue?

LOL! Back to the Future! LOL

Re: REST vs GraphQL vs gRPC

#146

Post by Mandatum »

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

That sounds like RPC with extra steps..

Re: REST vs GraphQL vs gRPC

#147

Post by sneak »

throwaway4good wrote: post #98
sneak wrote: post #95

Earlier quoted context omitted.

> Personally I prefer to have explicit control over the caching mechanism rather than leaving it to network elements or browser caching. I'm not talking about browser caching, I'm talking about the reverse proxy that fronts your ("backend") service to the internet. High traffic global/unauthenticated reads, especially those that never change, should get cached by the frontend (of the "backend", not the SPA) reverse p…

I am sure you have good reasons for your concrete design but in the general case: Why not simply build the caching into your backend services rather than having a proxy do it based on the specifics of http protocol? It would be simpler and far more powerful.

Because the backend app servers were extremely fat (memory and disk intensive) and every request they served that could have been served from an upstream cache was a request that they weren't serving that actually required all of their resources to serve.

Caching upstream on (vastly cheaper) instances permitted a huge cost savings for the same requests/sec.

Re: REST vs GraphQL vs gRPC

#148

Post by fragile_frogs »

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 am doing the same.

GET /api/module/method?param1&param2

or

POST /api/module/method Body: Json{ param1, param2 }

Re: REST vs GraphQL vs gRPC

#150

Post by jkoudys »

tshaddox wrote: post #116
stickfigure wrote: post #83

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

I'm not convinced that GraphQL is any more difficult to implement robust rate limiting or other performance guarantees than a REST API with comparable functionality. As soon as you start implementing field/resource customizability in a REST API you have roughly the same problems guaranteeing performance. JSON:API, for example, specifies how to request fields on related objects with a syntax like `/articles/1?include=…

Often the rates I'll end up limiting in rest aren't even bottlenecks at all in graphql. like if I wanted to grab a relationship that hasn't been implemented with its own resource endpoint.

e.g. get all the comments in every article written by one author, I might say `/author/john smith` that returns all their articles, then run an `/articles/{}?include=comments` for each one. That'll run a separate query server-side for each one, which can get very heavy if I'm doing thousands of queries. On the gql this is trivial as `{ author(name: "john smith") { articles { comments `, but because it's one request the server-side fetch can be run _way_ more efficiently. We have dataloaders for the SQL written that'll collapse every big query like this into (often) a `IN (?, ?`... query, or sometimes subselects. Same concept works on any sql or nosql approach. So yeah it might be "a lot" data were it RESTful, but we're not going to bottleneck on a single indexed query and a ~10MB payload.

The real advantage I see for REST in that scenario is that it can _feel_ faster to the end-user, since you'll get some data back earlier. Running a small query on thousands of requests is slower, but you can display the first little one's result to the user faster than a big gql payload,.

Post reply on HN