GraphQL: The Documentary

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. ▶ this video

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] ▶ this video

> 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. Meanwhil

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]: ▶ this video

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] ▶ this video [1] link [2] link [3] link