Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GraphQL vs. REST APIs: a complete guide

airplane.dev

Post reply on HN
Print view View original

21–30 of 103 posts

Re: GraphQL vs. REST APIs: a complete guide

#21

Post by berkle4455 »

gofreddygo wrote: post #19
twodave wrote: post #17

I like GraphQL because it allows me to describe my API like a domain rather than just a collection of resources. REST is difficult to map to a true domain model because domains aren't just collections of resources. They have nuance. And with GraphQL your API matches your domain, so there's no limit to what your application can accomplish. For example, adding another feature to your front-end no longer requires going…

I love graphql. It allowed me to scrape a whole bunch of websites with almost no changes to my scraper.

graphql is a data exfiltration engine, it's lovely

Re: GraphQL vs. REST APIs: a complete guide

#22

Post by jensneuse »

flashgordon wrote: post #18
jensneuse wrote: post #9

Here's how you do it: - REST/Hypermedia when you're actually building a website (not app) and your "site" is a state machine - OpenAPI when you expose and API to 3rd parties - Isomorphic TypeScript APIs when you're using TS on both backend and frontend [0] - GraphQL when the frontend needs to talk to an API layer provided by different teams - OpenAPI when one backend talks to another backend - gRPC might be an option…

One thing Id suggest - "gRPC might be an option but most teams dont need it" - needs a revisit. As a backend-dev (who does front end when needed - and that too by slapping NextJS on an API) I have found starting from a grpc set of services and generating http/openapi specs from it to be much for maintainable and understandable than starting with the OpenAPI spec and working "inwards". Apart from a (mostly) single sou…

If we compare gRPC to OpenAPI, we get the following. gRPC will be faster at the tradeoff of complexity. You need more tooling, you cannot easily inspect binary traffic, you cannot simply call gRPC from the web, you need a grpc web proxy, proxies and API gateways are more complex for gRPC than for an OpenAPI/REST-ish API, and the list goes on. I can put my protobuf in a registry, but the same applies to OpenAPI. So what really is the difference? And do we really need the gRPC level of performance with this hefty price of complexity? I doubt it. Most of the time, your database will be much slower than what gRPC might give you in performance compared to OpenAPI.

Sorry if I'm pushing back on this. It's not against you. I've just seen way too many devs and teams who created gRPC "micro" services and all they needed was one boring well designed OpenAPI monolith with good architecture.

gRPC is great if you really really have the problems it tries to solve. I believe most companies have a much bigger problem than performance, the inability to design APIs. You cannot solve bad API design by using a faster tool. Fix your API design, OpenAPI is great.

Re: GraphQL vs. REST APIs: a complete guide

#23

Post by jensneuse »

lazyasciiart wrote: post #20
jensneuse wrote: post #9

Here's how you do it: - REST/Hypermedia when you're actually building a website (not app) and your "site" is a state machine - OpenAPI when you expose and API to 3rd parties - Isomorphic TypeScript APIs when you're using TS on both backend and frontend [0] - GraphQL when the frontend needs to talk to an API layer provided by different teams - OpenAPI when one backend talks to another backend - gRPC might be an option…

Why does OpenAPI appear to be an alternative to REST in your list?

I understand REST APIs more like Hypermedia APIs, where you go to the landing page, it contains links, you follow them, you leverage content types, etc... So by definition, a REST API has no specification, it's an API that the agent can explore.

In contrast, an OpenAPI is a REST-ish API with an OpenAPI specification. It's not as dynamic as REST, it's not Hypermedia, it's much more "JSON over HTTP" but also not exactly RPC.

Re: GraphQL vs. REST APIs: a complete guide

#24

Post by zoover2020 »

coolgoose wrote: post #7

Well, seems somebody doesn't care about jsonapi/openapi and the rest of the family. Sparse field sets / compound documents are nothing new and I'd argue its easy to overlook that there's no magic in the backend for graphql either.

I think OP didn't make the distinction between RESt and RESTful APIs. A pity IG you'd ask me

Re: GraphQL vs. REST APIs: a complete guide

#26

Post by timr »

jensneuse wrote: post #9

Here's how you do it: - REST/Hypermedia when you're actually building a website (not app) and your "site" is a state machine - OpenAPI when you expose and API to 3rd parties - Isomorphic TypeScript APIs when you're using TS on both backend and frontend [0] - GraphQL when the frontend needs to talk to an API layer provided by different teams - OpenAPI when one backend talks to another backend - gRPC might be an option…

Simplify that to:

- REST by default

- everything else might be an option, but you need to justify it with specific reasons.

Also, having a JS-driven front end or multiple teams is not an automatic justification for the complexity of GraphQL.

GraphQL is a huge burden, for very little practical gain. Most companies have very small number of examples of conflict areas where queries need to be optimized, and for the most part, these can be resolved through smarter front-end engineering (like not throwing React at CRUD websites).

It's amazing how we managed to build large-scale websites with essentially all modern functionality without all of this stuff for years and years, and only since 2012 or so have these tools become "necessary" (and I'm being generous with 2012...it's more recent than that).

Re: GraphQL vs. REST APIs: a complete guide

#27

Post by WirelessGigabit »

I don't like that GraphQL is called GraphQL.

Its output cannot represent a graph. Its output is finite.

Consider an API that queries people. You query a married person and include their spouse. And then you include the spouse's spouse, and so on.

GraphQL will render as many levels as you request without deduplication.

JSONAPI will do this much better, you'll get 2 entities in 'data', and they'll refer to each other in their relationships block.

Not that I like JSONAPI. Having built larger system with it there is no universal way of supporting pagination in the includes section which makes it a binary proposition about includes. You get ALL the ones you request, or none.

Re: GraphQL vs. REST APIs: a complete guide

#28

Post by shagie »

jensneuse wrote: post #23
lazyasciiart wrote: post #20

Earlier quoted context omitted.

Why does OpenAPI appear to be an alternative to REST in your list?

I understand REST APIs more like Hypermedia APIs, where you go to the landing page, it contains links, you follow them, you leverage content types, etc... So by definition, a REST API has no specification, it's an API that the agent can explore. In contrast, an OpenAPI is a REST-ish API with an OpenAPI specification. It's not as dynamic as REST, it's not Hypermedia, it's much more "JSON over HTTP" but also not exactl…

Building on this...

Look at https://api.github.com/users/octocat

Or the OpenID Connect and /.well-known/openid-configuration https://openid.net/specs/openid-connect-discovery-1_0.html

And while I might be invoking scotsmen, very few things look like https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc... and so are best described as "REST like" or "RESTish".

Re: GraphQL vs. REST APIs: a complete guide

#29

Post by flashgordon »

jensneuse wrote: post #22
flashgordon wrote: post #18

Earlier quoted context omitted.

One thing Id suggest - "gRPC might be an option but most teams dont need it" - needs a revisit. As a backend-dev (who does front end when needed - and that too by slapping NextJS on an API) I have found starting from a grpc set of services and generating http/openapi specs from it to be much for maintainable and understandable than starting with the OpenAPI spec and working "inwards". Apart from a (mostly) single sou…

If we compare gRPC to OpenAPI, we get the following. gRPC will be faster at the tradeoff of complexity. You need more tooling, you cannot easily inspect binary traffic, you cannot simply call gRPC from the web, you need a grpc web proxy, proxies and API gateways are more complex for gRPC than for an OpenAPI/REST-ish API, and the list goes on. I can put my protobuf in a registry, but the same applies to OpenAPI. So wh…

Pushback is always good. I am not buying the argument (from having done large scale systems in both) that OpenAPI is significantly more productive than grpc - especially when building SaaS/control plane services. I do agree tooling is "prettier" for OpenAPI but that is artifact of needing that level of tooling for a spec that to me never felt as expressive to begin with (have to be careful not to get into Yaml vs syntax wars her). On the contrary reading/modifying/consuming grpc specs have never needed a custom UI. OpenAPI is way too tied in the hip with http (doesnt need to be) and a lot of things evolved that way. Grpc never had this problem. As you may have pointed out it needs an extra grpc-gateway plugin to generate a http gateway (which I actually is neat)

+1 on the terrible state of grpc cli tooling (unless you are already working at a faang).

-1 on Web proxy - As mentioned before I actually find that seperating a http "transaltion" gateway from your core biz logic is a win in my mind.

+1 On way too many microservices. IMO whether you use GRPC or OA, you can build monoliths or way too many microservices. I have not felt GRPC explicitly enforced that. What I did get from grpc is the logical seperation with grpc (you can still bundle multiple services in a single binary vs as seperate microservices) if you want. With grpc (nay proto spec) building a service becomes a logical exercise over how do i structure URLs vs what verbs to use etc.

PS: On a completely diff note I actually like your approach to isomorphic types. My switching to the grpc side was largely motivated by this single source of truth from whence all layer specific types came forth from!

Re: GraphQL vs. REST APIs: a complete guide

#30

Post by foota »

WirelessGigabit wrote: post #27

I don't like that GraphQL is called GraphQL. Its output cannot represent a graph. Its output is finite. Consider an API that queries people. You query a married person and include their spouse. And then you include the spouse's spouse, and so on. GraphQL will render as many levels as you request without deduplication. JSONAPI will do this much better, you'll get 2 entities in 'data', and they'll refer to each other i…

It's a query language for graphs, not a language for transferring graph data.
Post reply on HN