HN Theater @HNTheaterMonth

Watch this Honeypot documentation about GraphQL. Listen to what the developers tell which problems they had to solve when they invented GraphQL. You likely do not have any of these problems.

https://www.youtube.com/watch?v=783ccP__No8&t=875s&ab_channe...

I recommend to watch the documentation about the facebook people that invented GraphQL [1]. Listen careful to which problems they solved with graphql, then think about the problems you have to solve for your application. Most of the time GraphQL is not worth its tradeoffs.

[1] https://www.youtube.com/watch?v=783ccP__No8

⬐ andrei_says_

Would you be willing to highlight the problems they were solving?

Link for those interested :)

https://www.youtube.com/watch?v=783ccP__No8

> It is unclear that the total impact on performance would be significantly negative compared to the typical GraphQL API. Some of the problems also apply to GraphQL, people just need to constrain the query complexity in the end.

But yeah, it would bite Datalog more if not designed well enough, and it's harder to tackle Datalog than to GraphQL.

Other thoughts on this topic:

I love GraphQL but I would love Datalog more if the toolchain is as good as GraphQL.

There's a spectrum on API of simplicity and power -- on the left, there is HTTP/REST which could be seen as a primitive/naive way of describing API it's not consumer-driven at all. On the right there's Datalog which is a powerful way of describing API, it can maximize the flexibility of both the server and the client.

Things like 'map' and 'filter' became well-known to average programmers not very long time ago, though the elite programmers already knew them well half a centry ago. Datalog is definitely a very good idea for API, but I'm afraid it wound't be as popular as GraphQL if Facebook chose this route instead.

That being said, the industry always adopts things in a very passive manner, usually because the current solution is too painful to use, or almost couldn't solve the problem on new problem scale. There's a documentary[0] for GraphQL, the creators had enough of REST, they ended up with inventing GraphQL. It originally was to solving their data fetching problems, in the meantime it would solve others too. Meanwhile, it pushed the common understanding of API for average programmer from left to right on the spectrum. If it's close enough to the right, more and more people would discover Datalog and buzz other people to use it.

Just like type system, it's hard to expect the industry have a deep understanding on the topic itself. Type systems similar to Java dominates the industry for a long time, though ML already existed almost half a centry. Recently, languages like TypeScript tookoff because people need to type existing JavaScript. Then people would discover that the type system they used to is far from enough to describe existing code design. It's like a pandora box, new type operator would came out every release, until people realize there's a spectrum of type system (Lambda Cube[1]), and Dependent T ype would be on the same spot as Datalog on the spectrum.

[0] https://youtu.be/783ccP__No8?t=645 [1] https://en.wikipedia.org/wiki/Lambda_cube

So we invented a query language (GraphQL) to solve an orchestration problem?

Sorry but I don't buy this reason. Especially not to the question: "Why we don't use SQL as a query language?" especially because REST was around way earlier than GraphQL.

Your reasoning could be great to answer the question: "Why we like GraphQL where there are a lot of microservices?"

BTW, there is nothing inherent in the language in itself, if each microservices would be speaking SQL, you would simply need to optmize your SQL query, decompose your optimized SQL query creating simpler queries one for each microservice, send each of those queries to the relative microservices, compute back the final result.

If you replace "microservices" with "table" here you get the standard way an SQL engine works :)

Please, it is not that I am against GraphQL, but it honestly seems like some engineer at facebook was annoyed by SQL, and decide to re-invent it. And that we are all following him or she just because they worked at facebook, which seems unwise.

Maybe the use of types? But what is the difference between a type and something that belong to a table?

Anyway, I am looking now at [GraphQL: The Documentary (Official Release)][1]

[1]: https://www.youtube.com/watch?v=783ccP__No8&feature=youtu.be

⬐ bryanrasmussen

There is nothing about GraphQL that makes me think someone invented it because they were annoyed by SQL and decided to reinvent it, generally reinvention means a lot of similarity only badly done. You might argue GraphQl is badly done in comparison to SQL, but surely not that it is similar.

⬐ siscia

Honestly I don't use it so often, but it seems that any query in graphql could be easily and automatically translated to a SQL query. Am I wrong?

There are definitely trying to solve the same problem, aren't they? What are the advantages of GraphQL over SQL?

Please, I really want to know the answer to this question.

The previous answer was "the infrastructure we build around GraphQL is better for microservices", ok I can see that. But it is the only answer? It seems like a little weak reason to create a language so that later you can create a new infrastructure around it.

Am I missing something?

Why you don't find GraphQL similar to SQL?

⬐ bryanrasmussen

Normally when I see a language that was created to fix problems somebody had with another language, then the two languages tend to be syntactically similar. I don't see any syntactic similarity.

Secondly I don't believe that GraphQl is meant to map to the relational algebra, which is the genesis of SQL.

GraphQL's benefit seems to be that you should be able to get all the data you need and nothing more with one query, and get it back in the form you want it. In the earlier comment that started this thread the commenter said something like that's what SQL gives you, but from my experience if you want to get back complicated data (3 joins, many properties with same names) your SQL statement is going to be a lot more difficult to write and organize than your GraphQL query. Writing the queries is generally really straightforward and it is quite quickly clear how to structure a query to get what you want, and indeed if it is even possible to structure the query. Ease of declaring what you want is a valid reason for having a new language.

Structuring a query in SQL or most query languages are generally more difficult than in GraphQL - in my experience. This of course does not mean there are not places where it can get complicated - just generally not at query construction time.

I can't really say if having a new infrastructure is a weak reason for creating a new language, I guess that depends on the infrastructure that one needs. Languages are generally really powerful tools for doing things, so if you want to do difficult things with higher productivity than previously you might feel encouraged to create a new language as part of your endeavors.

⬐ siscia

I really like your reasoning, thanks.

While I agree that GQL queries are simpler to write, it is also true that they are much less powerful.

I personally don't believe that it is a valid reason for creating a new language and all this infrastructure, but for some kind of project I can see the attractiveness.

⬐ xwowsersx

> So we invented a query language (GraphQL) to solve an orchestration problem? Sorry but I don't buy this reason.

Exactly. I came here to say the same thing. This seems like an attempt to justify the existence of a thing after-the-fact. And it's a reason which isn't even the stated reason of the project itself!

1) I think GraphQL is more relevant than ever. Facebook ran into the same problems like Netflix, Airbnb and Twitter and thus came up with GraphQL [0].

2) The most popular one I know is GitHub's GraphQL API [1]. I made the difficult decision to rely on their API to teach GraphQL in my free book [2]. So far, there were no breaking changes for me and people love it to learn GraphQL from a client's perspective.

3)I would use it if I want to have no under-/overfetching, declarative data fetching, microservice API aggregation, ... [3]

4) Using it in personal projects and one client of mine is using it in one application to aggregate multiple microservices (each one speaking GraphQL) into one GraphQL API gateway. So far, everything works like expected. We didn't hit any rate limiting and caching issues because of the N+1 problem yet. But we are prepared for them :)

[0] https://www.youtube.com/watch?v=783ccP__No8

[1] https://developer.github.com/v4/

[2] https://www.robinwieruch.de/the-road-to-graphql-book/

[3] https://www.robinwieruch.de/why-graphql-advantages-disadvant...