Design a GraphQL Schema So Good, It'll Make REST APIs Cry

Where's the "crying" part? The GraphQL schema designed in this article is very trivial, nothing beyond a "hello world" level. There are no advantages to using GraphQL here, and many well-known disadvantages of using it anywhere. A REST API can have an endpoint that returns companies and their job postings, everything shown here can be trivially done in REST. And of course, there is nothing about how to actually implement it on the backend in a performant way.

GraphQL is an abysmal technology.

In terms of destructive power to the software industry it's almost on the level of OOP. The one positive seems to be that engineers are catching on to this fact at a much faster rate(5-10 years instead of 10-20). However, unfortunately, GraphQL sits in a position of the software stack that's very difficult to swap out, so even when engineers do realize the damage, they are stuck with it unless they change jobs. Extremely frustrating. Yes I'm one of those stuck engineers.

And then you have articles like this still touting it as some kind of rainbow miracle.

I'm not even going to list the countless issues you will be encountering by committing to this tech, or the fact that the mitigation of those issues will result in essentially gravitating back to REST with several unnecessary and convoluted translation layers. Instead, I invite you to research how Meta, the company behind the technology, is using the technology in practice. Just open Facebook and look at the /graphql queries, or read some articles by Meta engineers.

Just had a quick read not sure why it's supposed to be so good ...

I love the section on documentation: https://tailcall.run/blog/graphql-schema/#step-10-document-y...

The most useless documentation is followed by:

> Good documentation helps both your team and API consumers understand the purpose and usage of each type and field.

I apprecciate the article, my own experiences have been dismall. GraphQL seems like a boon but in my experiences ends up being slow, overly complicated and extremely hard to read.

May be me though

An article which was posted on HN a few months ago, "Why, after 6 years, I’m over GraphQL":

https://news.ycombinator.com/item?id=40521518

GraphQL doesn't solve engineering problems it solves human problems. It's a mechanism to patch bad employee communication

I've developed one thing that uses a GraphQL API and crying is definitely what I wanted to do. Why is it my job to dig through your schema to get a response that would be just a simple GET request or two with a REST API?

I see a lot of negativity in this thread about GraphQL. As someone that's gonna be building a backend API soon, what's your favourite article/guide to build a REST API at scale assuming that GraphQL is overly complicated for our use case? I'm probably going to have to explain the main differences or at least contribute my own opinion so any link would be appreciated.

We mainly use python and we're probably stuck with MSSQL. I've built simple stuff with FastAPI and even Flask before but nothing serious.

Has anybody used GraphQL for Data Science access?

As a strong DDD advocate, the core idea of GraphQL makes me scream on the inside. It turns explicit FE/BE contracts into implicit ones and you lose out on valuable domain insight.

However, if you have a purely read-only use-case with no way back to the BE, then maybe it's a nice tool actually? Especially since Data Guys often lament not having access to the full DB and making specific endpoints for them get tedious really quickly.

You don't need GraphQL for the same reasons you do not need to sync your state between the client and the backend, everything can be done with htmx and one source of truth for the state.

GraphQL is their business, so take this article with a grain of salt, it's not objective at all. It's on their best interest to promote GraphQL.

Graphql adds an extra layer between client and server. You may gain some benefits, but you get extra complexity and some performance punishment as well.

Despite my preference for it, I've become convinced that REST/Hypermedia is too hard of a concept for 2024-era development.

It requires a deep understanding of many ideas and people aren't able to grasp what it means and what it solves (hint: it is not meant to solve schema design). It ends up being a problem instead of a solution.

GraphQL (which is built upon REST, but has a simpler conceptual load) is way better for common everyday webdevelopment.

After a lot of crying no longer using GraphQL, just REST API-s

I mean sure you can devote some time to building a decent GraphQL schema, but will it really be worth the time/effort/investment when you can hack a painless REST API that can do all those dead simple CRUD operations easily?

Everything you described from posting jobs to searching candidates are dead simple POST and GET requests. No need to overcomplicate things…

Yawn. GraphSQL company promotes their blog. How does this make the front page?