Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
hinst138270dGraphQL is a framework in mankind's history
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.
sariel908970d@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.
kiki2802370d@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.
BixelPitch106470dAnd even for multiple data sources there are services that can combine them and provide a proper REST API. Didn't used it but there is a thing like hasura. Side question: are foreign data wrappers still a thing?
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.
sariel908969d@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.
n3xus353069dFirstly 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.
@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.
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.
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.
> 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.
@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.
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.
EmberQuill388766dMaybe 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.