Understand the pause, and if we were a social networking company I'd be more concerned - but already our decision to use GraphQL/React is paying off, as it differentiates for customers looking to integrate our product into their product due to the richness of the API that we are inherently providing.
GraphQL so far to me just seems like a way to facilitate freedom to front-end engineering in terms of not begin dependent on the back-end when query-ing; I image that when back- and front-end teams are separate that it can be frustrating to front-enders to wait for the api developers to have made something available to them.
At the same time I can see that it works in the other way around; back-end engineers don't have to keep up with changing query requirements from the front-end team.
The same is suggested in the article and confirmed in the response to the only comment:
"The point is that most APIs end up having to support lots of different client requirements all at the same time... and then those requirements change... and then they change again. You don't want to have "fix" your API every time this happens. GraphQL would support a lot of these differing requirements with no changes to the server code at all."
"You don't want to have "fix" your API every time this happens." I don't see why not. Requirements change thus code changes, its not a big deal.
The sacrifice you make with this 'not having to change the server side code' is that you are never able to change the server side code again without risking that you take away functionality that is somehow used by some client somewhere. I say 'somehow' because with REST there is usually an endpoint that is either used or not, but with GraphQL there are relations that get used through each other which is less straightforward to determine when pruning or updating your API.
It all depends who you are though. For Github it is probably a good idea to provide a GraphQL API as this freedom in the front-end will make adoption of their API and thus their service more likely. If you are a normal company and you are the only consumer of your API I highly question the added benefit.
I might be wrong though, so if anyone could point me at some high quality resources on the benefit of GraphQL I am very interested. This article wasn't really that.
> with GraphQL there are relations that get used through each other which is less straightforward to determine when pruning or updating your API
That can be easier since you can add metrics to each individual field rather than url, allowing you to deprecate rarely used fields knowing what you'll break and alert only those who are using it of the change
That could be true, but field would not be enough, at least in my limited understanding. I can imagine that I'd also want to know which information is retrieved through other pieces of information. So lets say `Post -> Comments -> Author -> Avatar`, rather than just `Avatar`. This is important because it shows that whatever I do I should at least support the relation to `Avatar` through `Post -> Comments -> Author`.
Is this "adding of metrics" to fields part of graphql api, or something the data store would provide? Apologies but I've only just started exploring graphql.
No, not part of graphql. Apollo Optics (no relation) is an option, or you can instrument the fields yourself just like you would implement any other instrumentation.
In an ideal world API versions would spawn feature-complete from version to version and older versions would require 0% maintenance, yes, but this is not how the world works.
As I said, it could work this way for Github, but not your relatively small SaaS. My point was that investing in these kinds of things might not be for everyone.
I'm the one suffering right now from graphql hype. The idea is great, but it's very immature. Android client is just not ready for something bigger then few simple queries. iOS client is also years behind JS client. If your platform is not limited to JS, It doesn't worth migration. We fighting with custom mutex and other painful tricks to make it working.
I'm one of the developers of the Apollo iOS client, so I'm definitely interested in hearing your feedback. I know we're missing some features compared to the JavaScript client, but both the Android and iOS clients seem fairly stable and are used in production. I'm especially intrigued by the need for a 'custom mutex and other painful tricks'. Maybe this isn't the venue for detailed discussion, but please open an issue on one of the repos or post a message on #android or #ios on the Apollo Slack so we can dive into this further!
I want to reproduce simple use case : header authorization , parallel requests , if token stoped , I want stop all requests that are behind in the queue, refresh my token, do requests again. Unfortunately your architecture limits us to JS style of development when failed request is ok, user will refresh the page. On mobile it's not the case. You close all the related tickets on github. So we build our own solution with mutex and other crap to make it somehow working in that way just because we already invested on backend in graphql. If not , I'd better avoid apollo and graphql.
I wouldn't call that an architectural limitation, but you're right the default network transport in Apollo iOS doesn't currently support your use case. You can plug in your own network transport implementation however, or integrate with something like AlamoFire for example. I'd definitely like to make this easier and document it better, but I don't think it's a good reason to avoid Apollo or GraphQL altogether. I'm not sure which issue I closed before, but please reopen it if you want to discuss this further and make the client work for you!
>Unfortunately your architecture limits us to JS style of development when failed request is ok, user will refresh the page.
On what planet is this "the JS style of development"? SPAs don't want to force the user to refresh the page for no good reason for the exact same reason that you don't want the user to close your app because their token has expired. The idea really isn't significantly different.
I find that GraphQL has a very complex syntax. While it has the benefit to avoid multiple requests and the time penalty that comes with it, I think it should be possible to define a simpler and more orthogonal query language.
Writing the same logic (querying + filtering) out in regular REST API calls and JS, or SQL queries, probably ends up with a similar complexity (if not more). It might be possible to create a simpler query language though, maybe with some middleware that converts it to a full GraphQL query. I guess it's comparable to SQL, and there's a number of alternatives / front-ends to SQL that will translate down to SQL.
Does anyone have experiences using GraphQL in production? Trying to understand if GraphQL will be a good alternative to REST for new projects or is GraphQL being hyped up like mongoDB was 7-8 years ago.
There are articles from GitHub, Shopify, Artsy, Walmart, Coursera, New York Times, and more! And these are just companies that have bothered to write an entire article about their experience.
This side-steps the legal question, but GraphQL is ultimately an idea on API design, and less about the corresponding libraries, such as the ones by Apollo or Facebook.
Of course the libraries are important too, but even if Facebook specifically strangled GraphQL to death, the idea of simple declarative HTTP API is too valuable to let it die on the vine.
In parallel, even if Facebook decided to strangle their React user base with patent trolling, and everyone decided to ditch React, the idea of a declarative DOM library or unidirectional flow is too good to let it die with React. And so we see it in Vue, Angular, and Preact or Inferno.
Hype may be related to many factors, one of which is mere library or ecosystem polish, often propelled by a big company with labor to spare, but I think the benefits behind a declarative HTTP API are real.
It is not a direct interface to the database backend
DB user roles for access control won't help much if you had the credentials to your db stored in javascript source so that the web front end can query your postrges db directly
Same as React: do not use if you plan to do anything that Facebook might dislike or steal, or want to sell your startup, or work in a bigger corp (ask the legal guys before).
This advice makes no sense for GraphQL, which is a _protocol_ rather than a piece of software. In fact, the perhaps most-used GraphQL implementation these days (Apollo) is not written by Facebook and is purely MIT-licensed.
Of course, you do need to ask yourself these legal questions if you use Relay.
The problem with that is it assumes that there's no logic on the back end, outside the database, that transforms data before sending it to the client.
If all you want is a way to submit SQL queries from a front end to a SQL database, you could just have the front end talk directly to the database. There's no need for a back end app in that case. But APIs are for talking to applications.
It also assumes all of the data is in one database. A common use case for GraphQL is to wrap multiple REST APIs and proxy calls to them as a "master API".
