Fully agree with the article. I think the summary is that GraphQL was a great idea from the frontend's perspective, but it was never fully worked out from a backend's standpoint.
After 6 years, I'm over GraphQL
11–20 of 721 posts
Re: After 6 years, I'm over GraphQL
#12GraphQL basically only really works with monoliths that share the same access-pattern (either everyone logged in, or everyone logged out), it's otherwise a pain to merge multiple different graphql-schemas into a single one (or at least I'm not aware of an elegant way to achieve that).. The worst of two worlds is a micro-services back-end with a graphql Api interface, it makes testing individual services and the Api a…
Hasura does role based access control pretty well.
Apollo federation and implementation of supergraph and nested graphs is pretty robust
We use both in production at reasonable scale and complexity 10+ roles few hundred object models, 100s of request/sec
Re: After 6 years, I'm over GraphQL
#13Haven't used GraphQL but the idea of exposing queries from the client directly to the DB is totally bananas, even behind a login with a separate auth. Even just explaining your DB structure is a thing you should not do.
Graph models need not be your tables . They should reflect your data models, the same kind of models that would have been exposed in a traditional RESTful API?
Similar concepts of allowing queries and response formats was there in other standards and not new ?
OData is fairly popular in REST world , even older , SOAP XMl had supported with custom query language one robust one I remember T-SQL used in Taleo the old Oracle hiring software
There are many examples of clients doing joins and queries in other standards , it is hardly unique to GraphQL
Re: After 6 years, I'm over GraphQL
#14Haven't used GraphQL but the idea of exposing queries from the client directly to the DB is totally bananas, even behind a login with a separate auth. Even just explaining your DB structure is a thing you should not do.
Not a fan of GraphQL (the problems mentioned in the post are very real), but GraphQL specification does not say anything about the DB design / queries. It is still an API layer and you are free to model it in any way you want.
Re: After 6 years, I'm over GraphQL
#15GraphQL was the shiny new thing that everyone was excited about and I was also trying to learn and use it too, but I've never found a compelling use-case to use it over REST API. Now that you shared your experiences with it, it give me more reason to stay away from it. Plus, I think it's more productive to stay with the stack I'm very fluent at.
[dead]
Re: After 6 years, I'm over GraphQL
#16A few weeks ago, I read that tRPC is an interesting alternative.
Re: After 6 years, I'm over GraphQL
#17[deleted]
Re: After 6 years, I'm over GraphQL
#18GraphQL is the peanut butter to Reacts chocolate at FB. It works there because 1. Every user is logged in. Is there anything you can do at FB without giving up something to the Zuck? 2. Because it's all behind a login, you can front load the first login/request with a giant SPA and then run all the custom queries you want. 3. everything at FB is some sort of blended context (my user, someone else's user, a permission…
What if Facebook wanted to open up parts of the site for users without an account, would that require a major reengineering? I've wondered why Facebook (and Instagram) are so strict about not showing anything to logged-out users, could technical reasons be part of that decision?
Re: After 6 years, I'm over GraphQL
#19[deleted]
Re: After 6 years, I'm over GraphQL
#20GraphQL always felt to me like it solved the easy part of the problem and offered nothing to solve the hard part. I have a similar response to things like Zanzibar. At the end of the day I want to go and get some stuff out of a database, and that complexity just ends up dominating everything.