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

Re: GraphQL vs. REST APIs: a complete guide

#31

Post by jensneuse » Fri, Mar 03, 2023, 10:20 PM UTC

timr wrote: post #26

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…

I more or less agree, but recent advances in tooling has changed this. E.g we've built a GraphQL to JSON RPC compiler [0], so we're hiding GraphQL behind a JSON RPC wall which also enables powerful code generation. We're using this successfully to build our own cloud [1] using our own tooling and I quite like it.

Shameless plug, I'd love to get feedback if you have the time to try it out.

[0]: https://docs.wundergraph.com/docs/features/graphql-to-json-r...

[1]: https://cloud.wundergraph.com

Re: GraphQL vs. REST APIs: a complete guide

#32

Post by timr » Fri, Mar 03, 2023, 10:24 PM UTC

jensneuse wrote: post #31

timr wrote: post #26

Earlier quoted context omitted.

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…

I more or less agree, but recent advances in tooling has changed this. E.g we've built a GraphQL to JSON RPC compiler [0], so we're hiding GraphQL behind a JSON RPC wall which also enables powerful code generation. We're using this successfully to build our own cloud [1] using our own tooling and I quite like it. Shameless plug, I'd love to get feedback if you have the time to try it out. [0]: https://docs.wundergrap…

I mean...ok, but...wow. You built a compiler?? For writing a web app? And you're not Facebook?

Look, maybe this is totally appropriate for your application domain. I don't know. But this kind of "power" is immensely complex. We have to be honest about the costs.

I have to keep reminding people that essentially all functionality of the modern web existed prior to 2012.

Re: GraphQL vs. REST APIs: a complete guide

#33

Post by IceDane » Fri, Mar 03, 2023, 10:25 PM UTC

timr wrote: post #26

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…

How is GQL a "huge burden"? Would you care to elaborate?

Re: GraphQL vs. REST APIs: a complete guide

#34

Post by senda » Fri, Mar 03, 2023, 10:26 PM UTC

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…

Should graphql ever be used to just cover all the basis of system integration?

Re: GraphQL vs. REST APIs: a complete guide

#35

Post by meowtimemania » Fri, Mar 03, 2023, 10:28 PM UTC

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…

The huge thing I love with graphql (and this probably works with OpenAPI as well) is run time mock generation. It makes writing tests a breeze and semi enjoyable.

example: https://www.freecodecamp.org/news/a-new-approach-to-mocking-...

Re: GraphQL vs. REST APIs: a complete guide

#36

Post by chrsjxn » Fri, Mar 03, 2023, 10:31 PM UTC

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's why I would pick GraphQL. It's a choice that reduces the barrier to rapid iteration in the clients, but it does add backend and infra work to support it.

Re: GraphQL vs. REST APIs: a complete guide

#37

Post by blagie » Fri, Mar 03, 2023, 10:32 PM UTC

I don't like GraphQL due to the complexity. It's not JSON or YAML, and requires a lot of custom stuff on both ends.

I'd like something like GraphQL, but built on standard data formats.

Re: GraphQL vs. REST APIs: a complete guide

#38

Post by timr » Fri, Mar 03, 2023, 10:32 PM UTC

IceDane wrote: post #33

timr wrote: post #26

Earlier quoted context omitted.

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…

How is GQL a "huge burden"? Would you care to elaborate?

I could write a book on this, but just a few:

* your teams will now spend a big portion of their time thinking about GQL primitives and mapping and syntax (oh my) and otherwise caring for and feeding this beast.

* you still haven't solved the underlying problem -- you still have to figure out why your GQL requests are hammering the back-end(s...let's not forget that a lot of this stuff came from poor decision-making re: microservices!), only now it's indirected and harder to optimize.

* ...oops, you forgot to implement all the corner cases of your GQL schema! Go back to 1 and start over.

Say what you will about REST, but the syntax is dead simple, it takes about 15 minutes to learn, and the semantics are crystal clear. Whatever complexity remains is actual complexity in your problem or org structure, and you should probably just fix that instead of trying to find magical tech beans to abstract the problem away.

Re: GraphQL vs. REST APIs: a complete guide

#39

Post by chiefalchemist » Fri, Mar 03, 2023, 10:35 PM UTC

timr wrote: post #26

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…

I haven't used it a lot but one of the benefits of GraphQL that caught my eye is you get to specify what you want returned. So, for example, instead of 20 product objects (all available properties) you can get 20 products with name and price.

Also, as I understand it, when implemented properly, you can get more complex (?) data back. For example, instead of getting 10 orders, and then 10 more requests for the items for each order, you can make a single request and get both in a single response.

I believe both concepts apply to creates / updates as well.

Re: GraphQL vs. REST APIs: a complete guide

#40

Post by timr » Fri, Mar 03, 2023, 10:38 PM UTC

chiefalchemist wrote: post #39

timr wrote: post #26

Earlier quoted context omitted.

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…

I haven't used it a lot but one of the benefits of GraphQL that caught my eye is you get to specify what you want returned. So, for example, instead of 20 product objects (all available properties) you can get 20 products with name and price. Also, as I understand it, when implemented properly, you can get more complex (?) data back. For example, instead of getting 10 orders, and then 10 more requests for the items f…

> but one of the benefits of GraphQL that caught my eye is you get to specify what you want returned. So, for example, instead of 20 product objects (all available properties) you can get 20 products with name and price.

Sort of (the sibling comment explains well why this example is an illusion). But even if this were an advantage, you have to implement the logic (simple in this case, but not so simple once people go hog-wild with the GQL). Also, I don't think I've ever had a situation in my career where loading name and price is a significant burden over either field individually. On the other hand, it's a huge burden to have to implement the back-end system that supports a fully orthogonal, structured query language for the UI.

To be fully charitable to the argument you're making, probably the real reason people do this is because they want to decouple development between Team UI and Team Product and Team Pricing, and it's just "easier" to expose "web SQL" to Team UI and let them go nuts, rather than sitting down with them an exposing targeted endpoints that give them exactly what they need.

...but now you have N problems. Your web app has become an ad-hoc distributed query language executor, and you have to think about the semantics and load implications of all of that.