So I don’t get the hype behind GraphQL. Why is it so damn popular on one hand, on the other hand not popular enough to make an old fart like me want to spend time to learn how to use it?

I think that's because It's not a silver bullet. It's good for some things and not very good for others (like everything in life lol)

I don't have any experience with it, but we briefly considered it for a project and then used PostgreSQL anyway because there didn't seem to be any advantage for using the gQL approach for our service. Was a rather simple listing website with some filtering and search only... No reason to not use relational

@Hazarth GraphQL is not a DB. It's an alternative to standard rest APIs. It's nice if you can make use of the flexibility, but I wouldn't use without a good reason.

GraphQL let's the API caller define what data to get without you needing to design additional endpoints in advanced.

You can also auto generated it from db schemas and the like these days.

@Hazarth no disrespect, are you a dev? :)

@favoretti ye, though as I said I have no experience with graphQL, thought it was another document based DB. But hey, the more you know!

My point remains the same though. It's niche enough to not blow up in popularity. Static APIs are good enough for most uses :D

There are indeed graph databases like DevRant is based on
https://neo4j.com/blog/...

That graphQL has nothing to do with it is kinda confusing. Also a reason why I always forget it's name.

Standard api:
I have these endpoints and they require x input and give y output.
Breaking changes will generate new endpoints. If you want less or more data: throw it away or make more requests.
Graphql:
I have these objects and this endpoint. that gives you the output you are requesting.

This is my understanding of graphql.

The main advantage of GraphQL (as far as I know) is that it's more flexible than REST. You can have one single endpoint that returns any arbitrary number of objects, filtered by any number of fields, including only whichever fields the request specifies in the response.

In practice this usually means fewer requests and less extraneous data returned.

Using GitHub's API as an example, one GraphQL request could let you get the repo name and the titles and authors of the first five open pull requests of each of the first 100 repositories owned by three different organizations. You can't do that in a single REST request.

Downside is queries are more complicated to write and it's not as useful for certain kinds of data structures.

@EmberQuill I think you are referring to the N+1 problem.
https://shopify.engineering/solving...

TBH, some developers just don't care about an excessive number of database queries. We were building a rest API, some guy wrote a function that would call query builder in for loop. I guess it's easier to spot shitty queries in rest api.

Otherwise, graphql is really easy to use when code can be generated from db schema/typescript types/graphql.