Big missing con for GraphQL here — optimization. Doing the right thing in simple cases is easy; in more complex cases you’re looking at having to do custom operations based on query introspection which is an even bigger pain in the ass than using REST in the first place UNLESS all of your data is in one database OR if you’re using it as a middleman between your clients and other backend services, you have a single read-through cache like Facebook which allows you to basically act as if everything were in a single database.
REST vs GraphQL vs gRPC
131–140 of 168 posts
Re: REST vs GraphQL vs gRPC
#132Re: REST vs GraphQL vs gRPC
#133Re: REST vs GraphQL vs gRPC
#134Earlier quoted context omitted.
I can't speak to GraphQL, but, when I was doing a detailed comparison, I found that OpenAPI's code generation facilities weren't even in in the same league as gRPC's. Buckle up, this is going to be a long comparison. Also, disclaimer, this was OpenAPI 2 I was looking at. I don't know what has changed in 3. gRPC has its own dedicated specification language, and it's vastly superior to OpenAPI's JSON-based format. Bein…
I don't entirely disagree that gRPC tooling is nicer and more complete in some areas, but there's some misconceptions here. You can specify openapi v2/3 as YAML and get comments that way. However, the idea is that you add descriptions to the properties, models, etc. It's almost self-documenting in v3, and looks about the same in v2, although I've used v2 less so can't be sure. I can't speak to editor support, but ope…
All fair points.
I had forgotten about the YAML format; I probably skipped over it because I am not a fan of YAML. As far as the description features go, they're something, but the lack of ability to stick extra information just anywhere in the file for the JSON format severely hampers the story for high-level documentation. I'm not a fan of the "the whole is just the sum of the parts" approach to documentation; not every important thing to know can sensibly be attached to just one property or resource.
Re: REST vs GraphQL vs gRPC
#135Earlier quoted context omitted.
This post is just a brief summary of each protocol, I don't understand how it made it to the front page.
I think it’s because of the robust discussion in these comments.
I almost never read articles in HN.
If I see title "something something GraphQL" in HN, I do not think "ooh someone wrote an article about GraphQL".
I rather see it as "folks in HN discussing about GraphQL today!"
I can google and get tens or even hundreds of articles about GraphQL, but I won't get the "points and counter points: a discussion that I get here.
Re: REST vs GraphQL vs gRPC
#136Earlier quoted context omitted.
This is what I see as a huge misconception of GraphQL, and unfortunately proliferates due to lots of simple "Just expose your whole DB as a GraphQL API!" type tools. It's quite simple (easier in my opinion than in REST) to build a targeted set of GraphQL endpoints that fit end-user needs while being secure and performant. Also, as the other user posted, "edges" and "nodes" has nothing to do with the core GraphQL spec…
I don't disagree with you, but graphql just lends itself well to bad decisions and many times when I've poked at graphql endpoints they share these issues (missing auth after first later, exposing schema by accident, no depth/cost limit). I think a combination of new technology w/o standardized best practices and startups being resource constrained proliferates poor security with graphql. Of course, the same could ha…
> no depth/cost limit
Or you can do like us, there’s no depth at all, since our types do not have any possible subqueries.
Re: REST vs GraphQL vs gRPC
#137Earlier quoted context omitted.
This is what I see as a huge misconception of GraphQL, and unfortunately proliferates due to lots of simple "Just expose your whole DB as a GraphQL API!" type tools. It's quite simple (easier in my opinion than in REST) to build a targeted set of GraphQL endpoints that fit end-user needs while being secure and performant. Also, as the other user posted, "edges" and "nodes" has nothing to do with the core GraphQL spec…
I don't disagree with you, but graphql just lends itself well to bad decisions and many times when I've poked at graphql endpoints they share these issues (missing auth after first later, exposing schema by accident, no depth/cost limit). I think a combination of new technology w/o standardized best practices and startups being resource constrained proliferates poor security with graphql. Of course, the same could ha…
I think I would agree. I'm a huge GraphQL fanboy, but one of the things I've posted many many times that I hate about GraphQL is that it has "QL" in the name, so a lot people think it is somehow analogous to SQL or some other generic query language.
So you get these very generic GraphQL APIs that map closely to the DB, when the exact opposite should be the case, that the APIs map as close as possible to the front-end use cases, and data is presented so that the front ends should need to have little, if any, customized view display logic. It even says so at the beginning of the spec:
> Product‐centric: GraphQL is unapologetically driven by the requirements of views and the front‐end engineers that write them. GraphQL starts with their way of thinking and requirements and builds the language and runtime necessary to enable that.
Re: REST vs GraphQL vs gRPC
#138Earlier quoted context omitted.
You don't get much more human readable than GraphQL syntax. There are now oodles of code generation tools available for GraphQL schemas which takes most of the heavy lifting out of the equation.
Do the code generators create efficient relational queries? I don't know about everyone else but my production data is highly relational.
Depends on the implementation. I've been using PostGraphile which says "PostGraphile compiles a query tree of any depth into a single SQL statement, resulting in extremely efficient execution".
Re: REST vs GraphQL vs gRPC
#139Another 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…
GraphQl queries are often send over an HTTP endpoint. This allows you to take advantage of caching where necessary (but then enough apps don't cache HTTP either).
For example you want to make sure large resource blobs (e.g. pictures are cached).
In this case you can decide to not put them in the GraphQl response but instead put a REST uri of them there and then have a endpoint like `/blobs/` or `/blobs/pictures/` or similar.
The same endpoints also can be used for pushing new resources (GraphQl creates a "empty" `/blobs/` entry to which you than can push).
While this entails an additional round-trip and is properly not the best usage for some cases for others like e.g. (not small) file up-/down-load it is quite nice as this is a operation often explicitly triggered by a user in a way where the additional roundtrip time doesn't matter at all. An additional benefit is that it can make thinks like halting and resuming downloads and similar easier.
Re: REST vs GraphQL vs gRPC
#140i 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…
> 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?