5 ms·
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
by ilovecaching 8y ago
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.
- ilovecaching 8y agoI 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.
- dmix 8y agoWhat language/framework was this being implemented on? If you dont mind me asking.
- ilovecaching 8y agoWe 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.
- misterbwong 8y agoOut 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.
- deleted 8y ago[deleted]
- joeevans1000 8y agoTeach 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.
- krainboltgreene 8y ago> considerably reduced the number of connections, wasted data, and made our client code so much simpler through easily grokked queries. I mean, you could have also just done this with what you had.
- ilovecaching 8y agoNot 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.
- hrktb 8y ago> 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). Am I missing something ? > REST necessitates multiple queries This is a self imposed limitation at best
- chillacy 8y agoYour 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.
- hrktb 8y agoWhat 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.
- dugword 8y agoWhat is a red haired resource?
- phailhaus 8y agoThink "red-headed stepchild". The weird ones.
- numbsafari 8y agoWhen 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.
- ilovecaching 8y agoEntities that one doesn't normally think of as a resource, such as an algorithm.
- ethagnawl 8y agoA wildly offensive analogy.
- lukeholder 8y agoI assume he means like a red-headed step-child. PC police might be on to terms like this nowadays, but by using the term I understood them to mean: - A less loved resource - A potentially ugly resource - A resource that causes trouble
- xtrapolate 8y ago"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.
- Zyst 8y ago>we were spending a lot of client time fetching deep trees through resource links >it solved a lot of the administrative and philosophical headaches >considerably reduced the number of connections >considerably reduced wasted data >made our client code so much simpler through easily grokked queries I feel that grandparent does contain information which might be valuable for adoption.
- CuriousSkeptic 8y agoMy 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.
- chillacy 8y agoFor 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.
- naasking 8y agoAlso 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.
- mrtbld 8y agoHow do you do caching with your GraphQL APIs ? I guess you can't leverage HTTP-level caching.
- wuliwong 8y ago>Highly recommmend GraphQL to anyone. 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.
- ilovecaching 8y agoIn 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.