Give me the good the bad and the ugly about graphql. I’m on the fence if I should learn that

@chatgpt Give me the good the bad and the ugly about graphql. I’m on the fence if I should learn that

omplex than setting up a basic REST API, especially when dealing with advanced features like subscriptions and file uploads.
3. Caching: GraphQL's flexible nature can make caching more challenging, as it requires additional effort to cache individual fields or nested data.

The Ugly:
1. Performance Concerns: Improperly designed GraphQL queries can lead to performance issues, such as over-fetching data or creating deeply nested queries that strain server resources.
2. Security Risks: Insecure schemas or poorly implemented resolvers can lead to vulnerabilities such as data leaks or denial-of-service attacks.
3. Tool Fragmentation: Due to the rapid growth of the GraphQL ecosystem, there may be fragmentation in tooling and best practices, making it challenging to navigate the landscape.

Ultimately, deciding whether to learn GraphQL depends on your specific needs and goals. If you value flexible data fetching, strong typing, and a vibrant community, learning GraphQL could be a valuable ass

et. However, be prepared for a learning curve and be diligent in understanding best practices to avoid potential pitfalls.

The ugly: it was created by facebook. If you use it, then every time you go to the lavatory, a little miniature Zuckerberg goblin will appear, just visible out of the corner of your eye, watching everything you're doing like a hungry reptile and whispering "macadamia... macadamia..." over and over again.

The open source community might be able to ensure there aren't any actual backdoors in the code, but they can't stop the macadamia goblin watching you on the shitter.

the good: it's a great idea.

the bad: it's implemented horribly, it's better to stick with a standard RESTful API and manually adopt GQL-features as needed.

the ugly: it's made by facebook.

the good: It’s freaking genius!

the bad: Too many projects should be using it but they don’t.

the ugly: It’s not trivial to implement and it’s even harder to fully understand what it really is vs. what it is not. And when it should be used vs. when it shouldn’t. Many people think it’s an alternative for SQL. It isn’t.

@Lensflare My question is : who would use something like graphql or No-SQL knowing that it compromise data consistency, integrity, and reliability.

Sure SQL isn't perfect either, but for a database isn't data consistency, integrity and reliability something important ?

@Grumm what in earth makes you think that no-sql databases compromise data consistency, integrity and reliability?

@Grumm NoSQL is ACID compliant. The biggest weakness is as always the human using it.
@Lensflare wtf? Before I’ll make myself sound like a fool, GraphQL is an API standard, and SQL is a query language for databases. Who in your vicinity made such a comparison?

@netikras the reason I posted here is because actual human beings respond to my question. If I wanted someone to babble what every other sheep person says, Id go to someone who has a waifu pillow of Jordan Belford

@Chewbanacas well, the QL in GraphQL is the same as the QL in SQL, so it’s understandable that one could think that it’s just another thing for the same purpose.

You can also query some no-sql databases with graphql directly, which probably fuels the confusion.

@Lensflare the very same people probably write queries into the html files

GraphQL.. Came and went i my books, not impressed.

@Lensflare Because that is how they work...

https://cloud.google.com/discover/....

Because a few have made it ACID compliant is a good step forward...

@Lensflare Ok, I was to fast to compare it and assuming I was only talking about the different types of Query languages. Maybe I should have added REST or something :)

It was more about the journey of all these things. NoSQL solved a lot of problems but using it with REST api's other problems came. Then GraphQL comes around to fix those problems.

Now a new problem is coming. NoSQL database is not that great for using GraphQL API's. And now they are all switching to Dgraph...

@Grumm

> Now a new problem is coming. NoSQL database is not that great for using GraphQL API's. And now they are all switching to Dgraph...

Please explain.

@Grumm I mean, ArangoDB for example supports graphs, so doesn’t graphql fit this like a glove? Or am I comparing Java to JavaScript here?

@Lensflare https://thenewstack.io/graphql-and-...

GraphQL is a strongly typed language. NoSQL a weakly typed one. (I guess same as javascript and typescript)

@Chewbanacas No, you can use graphQL on any database. ArangoDB and others are now starting to create a layer on NoSQL databases that defines the types supported by the API, the names of fields that can be queried and the types of queries that can be made.

@Lensflare "what in earth makes you think that no-sql databases compromise data consistency, integrity and reliability?" - the people who use them usually have no clue what they're doing and are producing sub-par code

@Grumm no-sql is not a language at all.
This term just covers any database that isn’t a relational sql db.
You seem confused.

@Lensflare I don't think so. In a NoSQL database, you can put in the same field '2' or '2.2' or even 'coef: 2.5'

And when you assume in your graphQL that it is an integer, thinks will break.

At what point do you think I confuse no-sql with a language ?

@Grumm

> At what point do you think I confuse no-sql with a language ?

At this point:

"GraphQL is a strongly typed language. NoSQL a weakly typed one. (I guess same as javascript and typescript)"

You mean every nosql db doesn’t have a mechanism to enforce types on properties?
I honestly don’t know but I would assume that it is possible.

But even then, it's not an issue unless you enter your data into the db manually for some weird reason.

In practice you would use some language like graphql to feed the data into the db. And there wouldn’t be any type issues because graphql is typed.

@Lensflare Yes, a NoSQL database as a few flaws: the lack of a database schema, data clustering, replication support and eventual consistency.

Now, most have made it ACID compliant. I agree with that.

You say this is not an issue. Well Javascript is also weakly typed. Are there issues that a string can be a number ? probably not as long as you write good code. But they still created typescript to "fix" this.

Same is now happening with NoSQL. the GraphQL is helping a lot and the makers of databases are adding the ability to have predefined schema's for NoSQL databases.

On the Wikipedia page, you have a nice list : https://en.wikipedia.org/wiki/NoSQL

@Grumm weak typing is a big issue of course.

I think I made it quite clear what I mean by "no issue": If you use a strongly typed system to access the data in the db (and there is no reason to not to), it doesn’t really matter that the db itself is weakly typed.

@Lensflare Yes, that is very clear and true.

My feedback was based on using NoSQL when it was pretty new. And let's say I create a json, an other person makes an other json but put text in a birtday field, you have to make everything idiot proof. (And the backend was javascript...)

But yeah, for me all of that is the good of GraphQL

@Grumm Do you ever not have to make something idiot proof?

@donkulator When coding in C#, I am less worried that my senior could mix a string into an integer :D

So not make it idiot proof to users but also to contributors