Hacker News Reader

Comment by endisneigh | Hacker News Reader

What exactly is the simpler solution that doesn’t result in your same cons mentioned?

There are patterns that can get you the same benefits without having to use GraphQL.

Even on a REST API, you can achieve the same pros

> - It makes working with describing the data you want easy > - It can save you bandwidth. Get what you ask for and no more

You can describe the fields you need (and I assume that is what reduces the bandwidth)

GET /users?fields=name,addresses.street,addresses.zip

> - It makes documentation for data consumers easy

I don't think so in practice. You can see Shopify's GraphQL documentation [1]. If anything it is more complex than their REST API docs

> - It can make subscription easier for you to use

Not too different from using something like SSE or even websockets and every decent web framework seems to have a decent implementation

> - Can let you federate API calls

So many ways to achieve this at the application layer (which is what GraphQL federation does with a Router). In the python world this could be separate WSGI apps or racks in ruby? And makes no difference if done at the load balancer level.

[1] https://shopify.dev/api/admin-graphql/2022-07/enums/localiza...

There a lot of ways to do the same thing as GraphQL. The point is if it’s as easy.

SQL statements wrapped in function calls.

Making a regular api

A regular api poorly implemented will have all the same cons and none of the pros.

Just make a perfect api without any drawbacks.

GraphQl has a set of trade-offs. REST also has trade-offs. Bespoke RPC calls have trade offs. It's as if the entire discipline is an exercise in selecting trade offs or something.

Well put. Problem is we can get emotionally invested and tie our identities to these systems in a way that we couldn't if we were comparing the trade-offs between 18/10 and 18/12 inox steel.

> A regular api poorly implemented will have all the same cons and none of the pros.

Okay, so don't make a poorly implemented one?

Also, no, it kind of won't. Let's look at what they are again

"It is actually a pain to use"

Not an API characteristic

"you'll have to manage two or more type systems if there are no code first generates in your language"

Not an API characteristic

"It doesn't support map/tables/dictionaries."

Not an API characteristic

"No clear path for Api versioning"

Not an API characteristic

Looks like it's actually zero for four

In order to build a properly implemented one, one must first learn to build one. I find most people jump onto graphql because they see the volume of work to create crud endpoints for all of their models and decided to punt.

It’s a false promise. You’re just moving the complexity elsewhere, into wiring this ridiculous graphql infrastructure together and making it actually do what you want in all but the simplest/tutorial-like scenarios.

Seriously. I sometimes think I'm visiting a satirical alter realm when I see these obtuse systems that end up requiring more cognitive energy to glue together than the regular version in <lang of your choice here> being praised rather than derided.

> I sometimes think I'm visiting a satirical alter realm when I see these obtuse systems that end up requiring more cognitive energy to glue together than the regular version in <lang of your choice here> being praised rather than derided.

You're lucky, you're only visiting. I'm working in that alternate reality :-)

Reply on news.ycombinator.com