Absolutely. Before GraphQL we were making a monumental effort to build a REST API. After deliberating on exactly what REST was and how we’d represent a few red haired resources, we were spending a lot of client time fetching deep trees through resource links. When we moved to GraphQL it solved a lot of the administrative and philosophical headaches and considerably reduced the number of connections, wasted data, and made our client code so much simpler through easily grokked queries. Highly recommmend GraphQL to anyone.
I should also mention that we finished our migration ahead of schedule. It was super easy to have GraphQL alongside REST, and we quickly iterated on converting each rest call to graphQL.
We’ve also found that on boarding our new hires is much simpler. There’s a lot of misinformation about REST, and we were having to retrain people, and when they wanted to see our schema we would then have to teach them swagger as well. With GraphQL we just send them to the official docs with our schema with is our single source of truth for the API and they come back a day later ready to go. Generally GraphQL being more standardized and centrally managed has been great from a training perspective.
Teach them Swagger? Do you mean to generate Swagger or to consume it? Because as far as clarity I don't think Swagger could be clearer, what with the interactive endpoint GUI and copy/paste curl commands and so on.
We wrote our own server in C++. We also have a few smaller graphql endpoints running the official JS implementation on express. On the client side we are using relay modern.
Out of curiosity, what does "tech them swagger" entail? I was under the impression that most of it was automated and that it's more of a standard than an implementation.
"We moved to GraphQL because things were bad, and now things are good. GraphQL is amazing".
I don't want this to come off as a personal attack (and I apologize if it does), but your comment contains absolutely no information whatsoever regarding a specific situation/use-case, nothing from which the rest of us can formulate our own opinions on the REST/GraphQL discussion.
My interpretation was: “We did ReST trying to follow dogma and ended up with a badly designed API that din’t fit our needs. Switching to a tech with less dogma on how to do things led us to a better API-design with a better fit” (inferring some context from my own experience here, could be wrong)
In the end I would guess you can end up in a similar place with a standard fetch-json design if you just ignore ReST dogma and focus on getting the API into a shape that fits the need.
Not saying ReST dogma is necessarily wrong, or bad, just that it’s easy to get lost in design when focusing more on learning others design than understanding the actual problem you’re trying to solve.
For reference we’re switching from the non dogmatic get/post requests over http to graphql and it’s been equally good for us too for different reasons.
Also consider that a second implementation of a system is always going to be cleaner than the first because you actually know what you need to do. This is an inherent bias inherent to any GraphQL migration story.
Not really. With REST, the server dictates the minimum requirements of the client. In GraphQL, the client dictates its own requirements, and the server is able to respond with no more and no less than what the client requires. Also REST necessitates multiple HTTP queries to fetch multiple resources. This is not a requirement of GraphQL.
> the client dictates its own requirements, and the server is able to respond with no more and no less than what the client requires.
The burden of dictating specs is just shifted around, and it seems the workload on the server side is bigger with h GraphQL (wider range of cases to handle).
Your graphql library will handle that for you. The server defines data as it knows, the client asks for data that it wants, and the library does the transform work.
What will the library handle ?
From my understanding it’s only the query parsing and the data filtering part. Correct me if I’m wrong.
You still have to do the data mapping, fetching everything from DB in a reasonable way, and make sure it all makes sense performance wise.
All of that will be needed for any API, but it seems to me GraphQL adds the uncertainty on how much data will be exchanged (lots of small queries ? a few big queries ?), what can be optimized, how will cache behave etc.
I remember a study on te github API on how some types of queries would make it crawl excessively. It fear it becomes a nightmare to try to cover for all the cases that can go wrong.
Yes, it handles data filtering, field renaming, etc, which turns out to be a big chunk of work if you're working on APIs to support multiple frontend experiences (the BFF pattern).
I don't know what your use case is, but it sounds like you should just try it, I can only say that for us (multiple FE experiences, pushing logic to backend), it's been very good. If you have a different usecase, ymmv.
Overall it acknowledges GraphQL's advantages, while warning that the data retrieval part shouldn't be done naively.
An excerp
> We note that this issue is somehow acknowledged by the Github GraphQL interface and, as a safety measure to avoid queries that might turn out to be too resource-intensive, it introduces a few syntactic restrictions [7]. As one such restriction, Github imposes a maximum level of nesting for queries that it accepts for execution.
However, even with this restriction (and other syntactic restric- tions imposed by the Github GraphQL interface [7]), Github fails to avoid all queries that hit some resource limits when executed
With a standard REST interface, you have to name all such combinations in advance. Possibly build custom code for each. With GraphQL, you specify them all at once, and are guided towards implementing code that will handle that. (There's no magic in GraphQL, of course, but the conceptualization alone can be useful. And if you're already in some particular ecosystem, they may have some localized magic you can use.)
You could just take your GraphQL backend and implement those specialized REST calls, sure, but then why not expose it?
There is a "standard" REST interface described in the paper on REST. There are a lot of rules/guidelines for a RESTful API but many API's don't follow them and tend to be a mix of REST and JSON RPC.
When I was a freshman in HS, a friend and I were playing Betrayal at Krondor late one night, just talking randomly about the stupid things that nerdy freshman talk about. At some point he just turns to me with this weird look on his face and says, completely ernest, "I just realized... I'm literally a red-headed step-child."
There was this long pause and then we both just started laughing.
File under: shit that doesn't happen any more because nobody plays single-player games side-by-side, late at night any longer.
This sounds a little over-the-top. There are certainly cases where REST would be the better recommendation over GraphQL. I have no idea what your specific requirements were but if building a REST API was a 'monumental effort' then GraphQL was probably a good choice for you. That does not mean that in all cases GraphQL > REST.
In my opinion, I think GraphQL offers enough over REST to be a total replacement. Especially now that the vast majority of clients are mobile, IoT, etc, the benefits of GraphQL make outlier cases rare. This is natural, the GraphQL authors had the benefit of hindsight. I'm not disparaging roy's work, it's a stepping stone. But REST as a design pattern was rarely implemented as he envisioned it. When it was done correctly, you end up with much of the same benefits as GraphQL.
