GraphQL fans, please read the whole rant until you jump in the comments.

I get it, when you have multiple data sources (that aren't always proper databases), your stuff is relevant.

But most of the people use GraphQL when they have a single database. In that case, native joins are always faster than GraphQL dataloader N + 1 BS you have. It takes less time and less code to go to the backend and write an endpoint for the frontend with a DB query than write several GraphQL ones on the frontend and then combine the data with imperative JS. It will work faster too.

So why the fuck should I use GraphQL at all?

GraphQL is a framework in mankind's history

Fantastic question,

I've worked on projects and whenever I'm writing a web API I opt for GraphQL.

It's not about join or query speed, it's simply about serving the data in a friendly manner for frontend developers or API consumers.

It also allows for you to deprecate and change things without versioning or worrying about it.

Yeah it's more complicated but it's equally complex as the technical debt that comes from legacy APIs. At least with GraphQL you have a pretty codebase to work with.

@n3xus I think fetch('whatever/api/handle/made/for/frontend/specifically') is more friendly than trying to install Apollo and get it working. At least it's my experience. Also, not everyone uses React.

@n3xus I agree with this. Frontend devs are notoriously lazy and would rather sit and wait for the backend to be completely rewritten before reading one page of documentation.

They also dislike being held to specific versions so they are free to push changes to the app 24/7.

Usually when the gql becomes far too complex to maintain a new js solution comes along that requires a full rewrite so it's not a problem.

Clearly graph is a superior solution that gives the flexibility that FE devs have become comfortable with.

It's those backend devs that need to get with the show and stop trying to make things work like systems have for the past 70 years.

@sariel bold of you to assume personal traits such as laziness based on the job title and to speak for “all” frontend developers.

GraphQL has no joins unless they are coded on the backend. If you have a simple autogenerated GraphQL CRUD, you won't be able to join two entities based on an arbitrary field from the client side. This is why frontend devs write two separate queries and then “join” them together iterating over objects in JS. This takes a lot of time, a lot of code, and has poor performance.

This is why I make custom endpoints for every frontend screen. 20 lines of SQL replace 400 lines of JS when it comes to manipulating data. And native joins work faster too.

The only case for GraphQL is when you have multiple datastores, and some of them aren't databases.

Saying that graphql has no joins does not make any sense. Graphql is supposed to give you the data already completely structured. It’s not relational. It’s a graph.
The join might happen on the DB before the result is delivered via graphql.

If you get entities from graphql that are supposed to be joined, then it was modeled by someone who doesn’t understand graphql.
Same goes for CRUD.
While you can technically model your typical crud access with graphql, it’s not designed for that. Graphql is supposed to be like the Aggregate in DDD. It should be modeled for access in a specific domain.
If used correctly, the advantages become clear.

@kiki every FE dev I have worked with fit into my description. I made a very broad generalization based on years of my experience. This isn't a fact, but I know I'm not the only one that feels this way.

As someone who used to do FE dev, I can't stand to work with lazy fuckers. I also can't stand POs that demand features in half the time necessary to deliver.

Firstly someone mentioned installing Apollo, for GraphQL you don't need to use Apollo whatsoever. It can receive JSON and can return JSON.

Also Apollo/GQL isn't react specific. I've consumed GraphQL with Vue, Java, Go and PHP all without issue using built in rest clients. Apollo gives some niceties but it's not required.

Also in terms of auto-generated GraphQL I'd agree it's stupid and probably not very helpful. Custom developed GraphQL APIs are the way to go no doubt.

@n3xus why? Sql is faster

@kiki SQL is a layer below GraphQL, usually.
You make a request in the frontend.
Data is fetched from a DB with SQL. The joined result is handed over to GraphQL.
GraphQL hands the result to the Frontend.
The result is all the data that you need for a use case, aggregated, with all the "entities"/models in a hierarchical structure.

@Lensflare complex join handled on SQL level will be faster than the same join on GraphQL level

@kiki there is no join at graphql level! You can and you should do it all in sql. I don’t know how else I should say it. I’ve said it 3 times in different ways now.
SQL is not an alternative nor a competitor for GraphQL. It’s more like an implementation detail.

@Lensflare that's my point :) this means you will have to make two separate fetch requests from your frontend. The only thing I want to say is that if you have just one database, making frontend-specific endpoints is faster, lower on code, and they will work quicker

One more thing:
Non-Relational databases (like MongoDB) can be used instead of an SQL DB, too.
You can change it and the clients using GraphQL won’t notice because GraphQL abstracts it all away for the clients.
It’s a better fit, too because you can more directly query the hierarchical data without the need to figure out the correct SQL to fetch it and translate from the relational to the hierarchical structure.
Performance depends. It will have bad performance if modeled for being the same useless CRUD that the people are used to.
It will have great performance if modeled correctly with the domain and use cases in mind.

@kiki I still don’t know why you think it would require two separate fetch requests or why it matters how many databases you have.

From the client, there is one request. The backend does the sql fetch and QraphQl gives the result back to the client.

GraphQL is lower on code also (for the client), because the client doesn’t need to join and transform the data. It’s already in the desired form according to the query.

@Lensflare okay, I think I get it. So far I only worked with autogenerated GraphQL APIs, they're just CRUDs. Maybe it is possible to do things properly, so the API looks good, but since it requires writing backend code, I prefer to just write custom REST endpoints.

> making frontend-specific endpoints is faster, lower on code, and they will work quicker

GraphQL is all about frontend specific endpoints! It’s exactly what it does. It minimizes the amount of code the fronted needs to write. If it’s quicker or not is not a question about GraphQL. It’s a question about what the backend does with those queries.

@Lensflare working with apollo in react required more code than just await fetch(url)

@kiki yeah it makes absolutely no sense to use GraphQL if all you need is crud.
GraphQL shines when you use it for specific frontend needs.
And it can get quite complicated to implement it correctly on the backend. Especially if you need to connect it to a SQL db.
That’s why it’s recommended to use a non-relational database instead. It’s just a much more natural fit and makes your life easier on the backend.

@Lensflare no, it's the opposite. I don't need crud at all. I need arbitrary data shaped specifically to be convenient to iterate over on the frontend. So, I have to transform the data from DB-specific schema to frontend-specific schema. If I have NodeJS backend and a SQL database, I can do it with either JS or SQL. By my experience, this kind of transformations are easier to do in SQL rather than JS. There will be less code this way. This is why when I need some data on the frontend, I go to the backend and make a new endpoint, which is essentially a wrapper for a SQL query.

@Lensflare I probably sound confusing. Essentially, the process is:

1. Fetch data from DB

2. Transform the data

3. Send it to the frontend.

We're talking about step two. Do we know the language that is very expressive and is perfect for data transformation? Yes, it's SQL. This is why I do things this way.

With SQL, there are the choices you have:

1. Query data on the backend with a simple SQL query. Transform the data on the backend with JS. Send in to the frontend.

2. Query data on the backend with a simple SQL query. Send the data as-is. Transform it on the frontend with JS.

3. Query data on the backend with a complex SQL query, so you don't need to transform it. Send it as-is.

I choose number three.

@kiki GraphQL gives you the language and the power to specify your query in the most easy and flexible way.
Use something like mongoDB and you don’t even need complex SQL queries on the backend.
No complexity, no manual transformation, practically no code, and good performance.

@Lensflare gotta look into mongodb. Last time I used it was in 2016, and I was in the uni. I heard it’s not as rigid as sql, and you can’t define models as precisely as with sql

@kiki yeah it‘s a bit… dynamic. But you don‘t always need the precision and complexity of sql dbs.

Sometimes you have multiple clients hitting the same API or even multiple screens wanting different perspectives of the same data.

It will be quicker at runtime to make something bespoke for everyone of them, but it’s a lot slower to build in the first place and can be never ending maintenance job.

One decent graph and they can do what they like. Great for rapidly prototyping UIs against.

Maybe I just haven't used a good GraphQL API yet, or maybe I haven't used it in ways that play to its strengths, but while I see the advantage of graph-based APIs, GraphQL queries are such a pain to write that I usually just opt for REST if there's a choice.

This is as an API consumer though. I mostly develop apps that access APIs not written by me. Don't know if the experience might be better if you own the whole stack.