What is GraphQL and why do i see it as a requirement in most jobs now

Just the next level of querying servers after soap, and rest

Frontenders wet dream. Backenders nightmare

The way I see it - a kind of ql that can be used by the frontend to qry entities on the backend.

Rest API combined into single endpoint, where all stuff can be queried in its jsonish language.

Multiple different stuff can be queried in one request, and language gives precision which resources are needed at the moment given, and which not.

Highly useful are least for some social network application with a lot of settings what to show and what not I guess

Basically, in most of cases you need just Rest API, but sometimes for some app types and size, makes sense to go GraphQL

Rest with bigger issues.

Instead of the below endpoints for example

/data/orders/*
/data/customers/*

You get /data and a post for everything which includes a query of sorts in the request to than fetch the data being asked for.

I'm more of a rest guy, I like explicitly asking for things and expecting an explicit response.

GraphQL on the other hand... feels like putting your database in the browser and saying, "here find your own shit"

@netikras why? That doesnt sound performant. It sounds like some kind of websocket tbh. Whats the difference?

In simple terms:
A way to shift processing to the backend, instead of "in the browser", to reduce network load.

Love it, or hate it - fb devs thinks it great.

@retoor well, not really. you can just use automapper and let entity framework do the rest.

but my question is: is it really that great for frontenders? i can see it being the perfect tool for it's use cases, yeah. but in my opinion, in the vast majority of cases, simple REST is better.

The major problem in having a single endpoint is that it violates the design of HTTP. If you're not writing a public API and thus keeping this hell to yourself, graphql is a great tool with the right dataset and backend

GraphQL was mostly invented for two reasons:

1) a simpler abstraction of data querying and definition

2) possibility of automation of testing, e.g. type introspection and other things make this possible

2) has an indirect / implicit requirement of 1) - GraphQL's language has certain limits, of some exist to be automated testable.

@b2plane Websocket is an entirely different thingamabob.

https://graphql.org/learn/...

Is imho a good start point.

What one should definitely mention is that comparing GraphQL and REST is like apples and pears.

GraphQLs basic idea are ... *drumroll* entity graphs.

https://graphql.org/learn/...

I think like any technicology, it can be used in good and bad ways.

Reason why FB loves it is simple: Given the size of FB, FBs engineering capabilities, FBs hardware resources for testing... GraphQL fits like a glove.

Testing can be automated, enough hardware is available.

Bandwidth / HW resources are taken care of by engineering - most likely optimization is done when it works.

The size of FB matters too - introspection is like reflection only in runtime. Features like that allow - when the necessary human resources for engineering / devs exist - quite a lot of runtime debugging / validation / ... to find out pain points.

The key is imho that one needs the resources for it.

GraphQL isn't a magic silver bullet. Like Rust, it doesn't happen magically, nor does it come for free.

It requires a severe change of thinking, lots of human resources to make *full* use of it's capabilities and then you can earn quite a few nice pros compared to other representations like REST.

Reason I mention the resources is because for most common companies who aren't large in size, the benefits are imho not there. If u use GraphQL just for data representation, it's like using Kubernetes for a simple OCI runtime... You can do it, but the costs are far too high vs its benefits.

@b2plane ws is a completely different thing. Ws holds an open connection fe-be all the time and ws ensures communication in full messages [you'll never send/receive only part of a message]. Http over tcp gives no such guarantees and is more low-level comm than ws. See? Not relevant to gql at all. You can use gql via ws or raw tcp socket.

Gql is on OSI-7 layer - it's an application protocol.
And its perf is quite alright. See, users may be running browsers on pentium 3 computers, and processing huge DTOs would make the website appear verryyyy slow. Gql allows to offload processing/dto transformations from the user's PC to the backend server. Also, using gql you don't need to create separate rest endpoints for each and every possible call. Meaning less maintenance, less niche code blocks, more generic codebase. But that comes at cost. IntrusionCM has covered it all very nicely imo

In my experience its an evolution on odata, its a way to offer up data so that the recipient can choose what and how much they want as they go.

Frontend can pick and choose without really involving backend.

Odata offer similar but has a clumsier structure for complex queries.

With a good graphql you could, similar to sql, merge data from multiple sources into one specialized response reducing the number of calls.

Google went the other way and optimized the http protocol instead but both strive to make fetching data faster and more efficient.

Graphql requires a LOT more work to setup to really offer all the benefits but if you have thousands of front ends devs it can be a better solution than thousands of specific rest endpoints that would need to be maintained separately.

If you have less than 50 devs you are less likely to be able to gain the full benefit unless the backend already have it covered.

A complex query provider like graphql will open a big can of worms where security is related :)

@Voxera It depends a bit on your enviroment.

If you define manually most of the graphs and thiers linmks/navigations, it can be a LOT of work

I'm basing graphQl backend on a modewl provided by Entity Framework, which already has navigation properties defined and all types / names of columns

Then you only need to add manually things like agregations or sums. For 85% uf usages in a front end, automatic model works just fine

@NoToJavaScript that could work but my experience with big datasets, like billions of rows, is that entity framework have its limits and can have a challenge to create fast queries :)

But yes with EF it should be a lot easier.

I'm terrified of entity frameworks.

Especially the ORMs.

It's mostly trading faster development for cancer.

ORMs are pretty much unremovable after a time, even with DDD (or whatever one might call it)... For very small and limited things, ok.

Larger projects / multi projects... Most likely digging its own grave.

@IntrusionCM I've seen so much ninja shit just to make things work with an orm. I don't know why people are so scared for sql

@retoor either that or some lower level, like e.g. JOOQ that just does "mapping magic".

My experience with ORMs and query generation is blessed with pain. If I got a scar for every trauma I experienced I would be invincible I guess, cause there was no healthy tissue left.

Just things like 'LOWER(column) LIKE "<injected quoted value>" CHARSET utf8' for case insensitive comparison to be compatible to different RDBMs implementations / versions MySQL like.

🤮

@IntrusionCM have you worked with Django? The auto generated migrations were quite nice

GraphQL has several practical implications.
Eg standard browser caching for GET requests is not there by default. Front-end resources for non-React implementation are limited.
There is an unofficial spec about how to handle multipart/form-data and binaries.
A back-end which is not powered by an async-context supporting runtime (like Node.Js) like PHP will require extra (OS-level) async abstractions to reap GQL benefits to their full extent.
GQL queries are only as performant as you make them: if you have an endpoint exposing a schema with data potentially coming from 10 sources and you do all the requests sequentially in the backend perf will suffer ofc

@retoor nope no Django experience

@IntrusionCM i was a few years with django and it was a bliss. I could just write my models and djamgo created an migration in python that works in 99 in all databases. If an type is missing the data is converted automatically apart from a small overhead on the server, the queries were executed with an very high perfomance. From what i can see nobody got near this.

@Voxera Oh yeah !

Our company start hitting this mark where just "YOLO" EF querries are not enought, you need to plan them and think :)

The good thing GraphQL provides is a centralization of querries.

So if I want a sum of whatever with these 'where" conditions, I only have 1 place in code to do that. And I can spend a day playing with indexes etc.

But right now I'm hitting a wall in my SQL understanding. Some qwueries, I just can't understand why it takes up to 3 secondes, while querry seems light, indexes are applied. But SQL still does a Bitmap of 38 millions rows.

Also, my GraphQL server uses a readOnly aproach and disabled EF entities tracking. This server is only used to get data, never to update it.