GraphQL vs. REST APIs: a complete guide • Hacker News Board

Re: GraphQL vs. REST APIs: a complete guide

#81

Post by dmitriid » Sat, Mar 04, 2023, 12:04 PM UTC

IceDane wrote: post #53

dmitriid wrote: post #45

Earlier quoted context omitted.

GQL, in no particular order: - GQL allows unbounded arbitrary queries. The awkward workarounds turn it into REST with none of REST semantics - default query method (POST) cannot be cached by literally anything in the infrastructure because POST is not cacheable by definition. The awkward workarounds require you to parse and look up fields in both request and response. Both of them arbitrarily large. - instead of dele…

> - GQL allows unbounded arbitrary queries. The awkward workarounds turn it into REST with none of REST semantics This is essentially a solved problem. You simply give all your fields a complexity value and then you limit the allowed complexity. > - instead of delegating requests to optimized queries (db or services) you now collect all that data manually, in-memory, on the server with little to no insight into what…

> This is essentially a solved problem. You simply

> you simply integrate

> or something

"simply", "essentially", "something". An equivalent of "just".

In reality: none of this is solved, non of this is "simply" etc. because every single lib and framework (often multiple for a language) will have their own awkward workarounds for these "solved" problems.

> Just not really an issue in practice, and really comes down to the underlying transport medium. JSON is limited

It is an issue in practice because every single framework does implement a date/time/datetime extension to built-in types. And this has nothing to do with JSON. Every single modern protocl for some reason forgets that dates, times and timestamps are sued everywhere and by everyone. See protobuf for example. Encodes to binary, has no dat representation.

> How is this a problem with GQL? Do you think that API versioning is in any way easier to when you have REST APIs?

Yes. API versioning is easy with REST API. You can even evolve schema versions for the same resource without ever changing the endpoint by looking at "Accepts" headers. When you have ad-hoc clients doing ad-hoc queries with GQL you can't even be sure which particular subset of data is requested by whom, and can you remove or deprecate or change it.

Yeah, yeah, here the "solution" is to use a hack called "persisted queries" which is literally REST but with all the good parts removed, and a lot of unnecessary steps added.

Re: GraphQL vs. REST APIs: a complete guide

#82

Post by dmitriid » Sat, Mar 04, 2023, 12:16 PM UTC

IceDane wrote: post #66

timr wrote: post #50

Earlier quoted context omitted.

I don't want to get into a debate about this. I've told you what I believe and why I believe it. I will add this: if you are truly at a company that has adopted GQL and you are not spending significant eng time on it, you're either not measuring it (ding ding ding!), or you're in the vast minority. Or maybe you're just too early, I suppose. Perhaps relevant to that point: the complexity of explaining GQL to an unfami…

> I don't want to get into a debate about this. I've told you what I believe and why I believe it. You've told me what you believe, but not why. You just made vague, handwavy assertions about things that you clearly understand rather poorly. Obviously you don't want to debate this, since your arguments are those of a flat-earther trying to explain their views. > I will add this: if you are truly at a company that has…

> It's not possible to build GQL query footguns.

GQL literally allows unbounded queries.

All the "tooling" around like "field complexity", "data loaders" and other hacks are literally that: hacks and workarounds, and they are not even consistently, evenly or even efficiently implemented among the various GQL libraries and frameworks.

> it automatically comes with documentation for your API

Unless it's specified in code, and to create actual documentation you have to run a server, connect to it with a tool, and dump it (can't remember which lib did that, was it in Java or in Go).

> you think that using GQL automatically comes with the infrastructure I described.

This: GQL doesn't come with infra. And for every thing that REST aready has and for every issue that GQL has, and REST doesn't, you need to add more and more infrastructure and "rich ecosystem":

- Caching is literally built-in in HTTP. GraphQL's default method is POST, so to "solve" caching frameworks like Apollo have to act as middlemen unpacking every incoming request and every outgoing response looking for certain fields to figure out what to cache. Of course, this isn't available in other libs and framewroks

- Unbounded queries are literally not an issue in REST (unless you build something weird). In GraphQL you need to "specify field complexity" if you framework allows that

- Your REST endpoints know what exactly is requested, and can have specific hyperoptimised queries for that specific thing. GraphQL is ad-hoc by nature, any query is potentially n+1, so you have the workarounds with dataloaders which by definition cannot be optimised unless your specific framewrok gives additional insights into what's being requested.

Literally everything around GraphQL is "nothing works well, and if you're lucky, a particular graphql implementation for your programming language will have some solutions for some of the problems".

How do I know?

I built a service prototype for an internal tool in 5 different languages with 6 different libs:

- Typescript, Apollo

- Java, graphql-java

- C#, graphql-dotnet

- go, glgen and graphql-gp

- Elixir, absinthe

GraphQL sucks ass for everyting and everybody except client developers who couldn't care less how it looks on the backend

Re: GraphQL vs. REST APIs: a complete guide

#83

Post by zelphirkalt » Sat, Mar 04, 2023, 1:06 PM UTC

timr wrote: post #70

Shish2k wrote: post #68

Earlier quoted context omitted.

> GraphQL is a huge burden I’ve recently been bolting graphql support onto a midsize legacy webapp with the goal of making native mobile apps easier, and so far I’ve been finding it remarkably simple and delightful — In fact implementing a graphql API so that the clients can specify which data they want for themselves has taken less time than all the design dicsussions about what a REST API could potentially look lik…

It's one those "the first taste is free" kind of things. If you're just doing the transition now, you'll have to take my word that there's more pain coming. It also matters a lot what you mean by "bolting on"...is anyone on the team actually using it? I will freely admit that, depending on the size of the team and the scale of the app, YMMV. For example, if you're the only person working on a legacy app that isn't un…

Also it matters, what kind of security requirements there are. Is it an API, that everyone can query to their heart's content? Or is there stuff some people may access and others are not allowed to see? Then suddenly there is a whole security layer in the game, that needs to be carefully implemented and tested. Did the thing I implement really protect the data of the API from all possible accesses by unauthorized people?

Re: GraphQL vs. REST APIs: a complete guide

#84

Post by diceduckmonk » Sat, Mar 04, 2023, 1:52 PM UTC

hbrn wrote: post #14

I really hate these bland, barely actionable advices with no examples, created for SEO purposes. Nobody knows how to measure the "complexity" and "evolvability" of the API and where exactly is the threshold that justifies going from REST to GraphQL. So here's my opinionated alternative: Use REST everywhere, unless you can justify the exception. A good exception is when you don't know the audience and use cases for yo…

> created for SEO purposes

I’ve always thought these posts were for non-technical product buyers and decision makers.

Re: GraphQL vs. REST APIs: a complete guide

#85

Post by diceduckmonk » Sat, Mar 04, 2023, 1:55 PM UTC

chrsjxn wrote: post #36

The article talks about how GraphQL is "flexible" a lot, but I kind of wish they'd spend more words talking about why that matters. Eg, if you're working on a new product, the odds are very good that your front ends will change pretty rapidly. At the very least, we're way more likely to A/B test application features than we are API schemas, regardless of what methodology or technology our APIs are using. Because that…

> "flexible" a lot, but I kind of wish they'd spend more words talking about why that matters.

I don’t think these articles exist for a technical audience or the bricklayers doing the integration. I think these are for the non-technical decision makers and business executives

Re: GraphQL vs. REST APIs: a complete guide

#86

Post by diceduckmonk » Sat, Mar 04, 2023, 1:59 PM UTC

denysonique wrote: post #3

For JavaScript based projects TeleFunc[1] can make development way simpler by 'removing' the need for an API. [1]: https://telefunc.com/

> For JavaScript based projects

This is viable for personal projects and things that exist in a vacuum.

Suppose you hit a performance bottleneck with your backend and want to migrate to Go

Or, if you want talk to your JavaScript background from a native mobile client. Or if another team or customer wants access to the API and not using JavaScript.

gRPC solved this problem by having Protobuf as the many-to-many translation layer. Client stubs and backend service stubs in a variety of languages are autogenerated. Telefunc is a subset of this wherein you define the Interface in TypeScript instead of protobuf. With gRPC you also get a binary encoding over the wire. Maybe the effort of the project could have been building on top of gRPC (which is not necessarily coupled to protobuf) and adding automatic codegen tooling for JavaScript.

Re: GraphQL vs. REST APIs: a complete guide

#87

Post by twodave » Sat, Mar 04, 2023, 2:20 PM UTC

marcosdumay wrote: post #54

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…

Yes, GraphQL allows you to expose a domain. What is a really big problem, because websites are organized as an hierarchy of resources, applications are organized as a collection of actions, and nobody on the user-facing side ever thinks about a domain of small interrelated things. With nobody thinking about the interface, you are left with the classical dilemma between usability and security. And all GraphQL tooling…

Thanks, this is thought-provoking. I went and did some reading—-am I mistaken for thinking simply disabling introspection in production is a hard counter to this? I realize for a public API (or API product) that isn’t super helpful, but for my own use cases nobody on production needs it.

Other than that, it seems that the answer is just performing object-level authorization to ensure you never leak resources a user isn’t supposed to have access to. Depending on the framework you use this can be pretty straightforward…

Re: GraphQL vs. REST APIs: a complete guide

#88

Post by twodave » Sat, Mar 04, 2023, 2:25 PM UTC

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.

How is this different than a REST API with an open api spec? I suppose GraphQL APIs are just more likely to have introspection turned on since it’s the default?

Re: GraphQL vs. REST APIs: a complete guide

#89

Post by blagie » Sat, Mar 04, 2023, 4:03 PM UTC

habitue wrote: post #78

mb7733 wrote: post #76

Earlier quoted context omitted.

Every graphql API I've ever seen returns JSON. It's definitely the standard. What are you referring to?

I think they're referring to the query language itself not being json or yaml

Exactly. It's not just not-JSON, but it's obnoxious and hard to manipulate programmatically, on either end (client or server).

That translates to a lack of tooling around it, an inability to write sane tooling, and difficulty interfacing in higher-order ways to things like interesting data stores. It's designed to be hand-written and parsed only with the official libraries.

Re: GraphQL vs. REST APIs: a complete guide

#90

Post by marcosdumay » Sat, Mar 04, 2023, 4:19 PM UTC

twodave wrote: post #87

marcosdumay wrote: post #54

Earlier quoted context omitted.

Yes, GraphQL allows you to expose a domain. What is a really big problem, because websites are organized as an hierarchy of resources, applications are organized as a collection of actions, and nobody on the user-facing side ever thinks about a domain of small interrelated things. With nobody thinking about the interface, you are left with the classical dilemma between usability and security. And all GraphQL tooling…

Thanks, this is thought-provoking. I went and did some reading—-am I mistaken for thinking simply disabling introspection in production is a hard counter to this? I realize for a public API (or API product) that isn’t super helpful, but for my own use cases nobody on production needs it. Other than that, it seems that the answer is just performing object-level authorization to ensure you never leak resources a user i…

Yes, if your data is not entirely public, you will need object-level autorization.

But the point is that no, it's not straightforward; the authorization must be designed to fit your needs. If you are not designing it, you can be certain that it's broken.