In what case should i use graphQL? I assume in a search bar?

Should i even use graphQL or is that an outdated technology?

If not supposed to use it what is the efficient way to use the search bar on frontend to search through specific backend routes in the api?

IMHO it's freaking stupid. You can aggregate data with any tech and i still prefer dem REST waii

@retoor so why do so many jobs require graphQL skills. What's the benefit of it compared to just normally calling a rest api

It makes sense when you use microservices and want to connect them together. Yeah otherwise I don't find it more superior than rest.

Seems like an excuse to shift responsibilities from backend to front end

@iceb but what exactly is graphQL doing better that rest isn't? Or even a bidirectional websocket?

@b2plane why do people use react? The world is crazy young man. Full of garbage

@b2plane in a monolith. probably nothing. In a microservices architecture it means a front end can fetch whatever data without backend having to make they want.

They can get data from different services with a single graphql call.

I would suggest googling graphql hacker news and read these super long discussions lol

they are quite interesting.

with an example of search bar. It makes sense for graphql because you might want to choose what columns you want to display in the results.
So you might have 3 columns out of the user table. one column for the number of crimes they've committed. and another completely unrelated thing like how many times they wrote google reviews or something.

So you'd define your types in graphql and fetch data from different sources. Front end gets to pick what they want with a single graphql call.

Again it makes sense when you have different sources or services. But not much sense when everything is in a monolith

GraphQL is used in cases where you need scalability. You tell the API endpoint what fields you are looking for and it gives u back the exact fields you asked for.

That said, It's not perfect in itself. The second the query size starts to get bigger it crumbles.

@iceb the search argument you use is not a good one. It's a super complex solution for something we do in REST for many years (fields selection).
There are some benefits in composing queries but here too I find JSON:API simpler more REST like. There are plenty of search engines that include a security model and API that easily translates to REST. There are some solutions that use GraphQL like a an API to data(base) access, then it makes sense to use it for a search use case just like the rest of the data access.

GraphQL has a place just like AI does but it suffers from the hype train overuse.
It's not outdated technology. It's a fairly new but mature standard. The implementations (server side) however vary in maturity. If you look for App-Sync you will find some nice examples.

@SidTheITGuy I have always found that a weird argument. Perhaps I'm doing REST wrong because of there is a certain usecase that suffers from the under fetching problem I tailor an endpoint towards that. REST is an API for me the implementation does not have to expose the underlying data model 1on1.
A properly shaped REST API should out perform and out scale GraphQL every time (because it's tailored everything can be optimized from cache to database without going through the GraphQL translations).

If you need a lot of these shaped endpoints your service has way too many responsibilities or is an aggregation layer. And the aggregation layer is where GraphQL does shine.

Search is not a good use case for graphql.
A search is basically a filter, or the WHERE part of SQL.
But GraphQL doesn’t help you with filters. It helps with selection and transformations.
So it’s kind of a SELECT and a JOIN from SQL, but in a json-like, hierarchical query language and response.

@Lensflare But it does !

I switched app to graphQl not because of flexibility of filtrers where and ordering / agregations !

Ofc, this doesn't come out of box and you need to implement it.

But, by it's nature, graphQl is very, very dynamic and everything (or most) can be implemented via reflexion.

So basiclly : Implement once, use it on any graph.

And possibility to select needed data, as you mention, is nice!

for me : gaphQl to consult data all the way, REST for updating / editing/creating/deleting data.

Put thewm on 2 seoarate servers, make graphQl read from replica. Poof, 50% of performance issues gone

@NoToJavaScript not sure where the contradiction is to what I have said :)

I mean if your search is nothing more than filter and sort, then you won’t get much value out of graphql, but depending on your search needs, graphql might be useful of course.

a general rule of thumb for every tool in every profession:

if you don't know when to use it - don't use it.

@tosensei I'm asking here

Trying to find a use case for GraphQL is pointless, I would say.

Normally your use case finds GraphQL:

You look for something more flexible than REST. You find GraphQL. You recognize how it will solve your problem immediately.

If you try to understand its utility by building something that you could do with REST as well, you will be disappointed and start hating it like many others that did that before.

@Lensflare i dont understand how graphQL works so i cant tell when should i use it. Im trying to understand use cases where it should be used so i can use it