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

161–168 of 168 posts

Re: REST vs GraphQL vs gRPC

#161

Post by tatersolid »

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 if you use HTTP caching, you can use a CDN with 100s of global locations. Which is quite a bit more powerful than any custom solution.

Re: REST vs GraphQL vs gRPC

#162

Post by thdxr »

sagichmal wrote: post #59
thdxr wrote: post #44

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

My experience has been extremely the opposite. It's likely the language you tried it with has a poor type system

Re: REST vs GraphQL vs gRPC

#163

Post by sagichmal »

thdxr wrote: post #162
sagichmal wrote: post #59

Earlier quoted context omitted.

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.

My experience has been extremely the opposite. It's likely the language you tried it with has a poor type system

Lol.

Re: REST vs GraphQL vs gRPC

#164

Post by applecrazy »

lazysheepherd wrote: post #135
applecrazy wrote: post #106

Earlier quoted context omitted.

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.

Wholeheartedly agree. The articles are often of average quality with a few gems here and there.

What I derive value from (once you tune out the pedantry) is the discussion by people knowledgeable on the topic. As a computer science student who tries to keep up with best practices, corporate adoption of technologies, and general trends in the industry, this is something I can't really get anywhere else.

I credit HN for giving me a balanced insight on things and indirect feedback on what's important to learn in order to make myself marketable when I graduate.

Re: REST vs GraphQL vs gRPC

#165

Post by ec109685 »

pavel_lishin wrote: post #151
ec109685 wrote: post #45

Earlier quoted context omitted.

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.

Cacheability isn't just about the transfer, it's also about decreasing server load in a lot of applications. An expensive query might return a few bytes of JSON, but may be something you want to avoid hitting repeatedly.

Sorry, they were addressing the two points from the comment above. I agree cacheability and transfer size are two separate aspects.

Re: REST vs GraphQL vs gRPC

#166

Post by TeeWEE »

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/

We are trying opeapi-generator and the experience is that the generated code for server stubs is either non existent, requires certain frameworks or is just not working.

So we had to write our own code generator templates. It was a pain compared to GRPC.

But yes, in theory it can be done.

Re: REST vs GraphQL vs gRPC

#167

Post by 5Qn8mNbc2FNCiVV »

verdverm wrote: post #118
andrew_ wrote: post #109

Earlier quoted context omitted.

Rate limiting and security are trivial these days, with an abundance of directive libs available, ready to use out of the box, and every major third party auth provider boasting ease of use with common GraphQL patterns. I'd argue what you see as the biggest con is actually a strength now. > And pagination is gross, with `edges` and `node` This just reads like an allergic reaction to "the new" and towards change. Edge…

I'd be interested to see a graphql library that makes security trivial. Could you add some links? In my experience, securing nested assets based on owner/editor/reader/anon was rather difficult and required inspecting the schema stack. I was using the Apollo stack. This was in the context of apps in projects in accounts (common pattern for SaaS where one email can have permissions in multiple orgs or projects)

Hasura makes that pretty easy as can be seen here: https://github.com/firatoezcan/hasura-cms

This is also easy to do with self-written servers, maybe take a look at the metadata folder to get a gist of what Hasura would be doing behind the scenes (running a query and then checking the claim for the condition for the given field that permission wants to be requested for)

(Just a repo I started one evening, it doesn't do much but the concept of projects with owners and collaborators should work)

Re: REST vs GraphQL vs gRPC

#168

Post by verdverm »

5Qn8mNbc2FNCiVV wrote: post #167
verdverm wrote: post #118

Earlier quoted context omitted.

I'd be interested to see a graphql library that makes security trivial. Could you add some links? In my experience, securing nested assets based on owner/editor/reader/anon was rather difficult and required inspecting the schema stack. I was using the Apollo stack. This was in the context of apps in projects in accounts (common pattern for SaaS where one email can have permissions in multiple orgs or projects)

Hasura makes that pretty easy as can be seen here: https://github.com/firatoezcan/hasura-cms This is also easy to do with self-written servers, maybe take a look at the metadata folder to get a gist of what Hasura would be doing behind the scenes (running a query and then checking the claim for the condition for the given field that permission wants to be requested for) (Just a repo I started one evening, it doesn't…

That's an end user experience on a platform. A library is something I can import into my own code to implement auth, without having to adopt a given stack. I wrote one, it's not simple (https://www.npmjs.com/package/graphql-autharoo)

Looking at the SQL and metadata, does not look all that simple for such a simple case. The complex part is behind all that, written by Hasura.

Imaging what that would look like with Orgs, Groups, and User permissions all existing on a single object, or even resource type, and how a single email (user) could have permissions at all of these levels on any object. Then consider that GraphQL allows nested query objects, so am I listing the objects as a top-level query, or is the list from a 1 to many relation nested under another query, where the query parsing system now batches these subqueries and presents them to the resolver in a big log. You have to understand the context of the incoming queries in each resolver, and then make auth decisions about it.

Think about using Hasure vs writing the auth systems in Hasura. Or how complex things get when you want to implement auth for multi-tenant SaaS.

Post reply on HN