You're going to get responses from people who have invested a considerable amount of time in something they already had plans for (a "sunk cost") so I'm not sure you will get the sort of information you are after here.
Ask HN: Were you happy moving your API from REST to GraphQL?
21–30 of 182 posts
Re: Ask HN: Were you happy moving your API from REST to GraphQL?
#22Absolutely. 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.
Re: Ask HN: Were you happy moving your API from REST to GraphQL?
#23Mostly, NOTE: I'm using python/django/graphene server side and apollo client side. I love how flexible it is for client developers and because the great client side libraries it helps to eliminate a ton of boiler plate code on the client side. My biggest complaint has been "lost" exceptions and caching. Because it's possible for an exception to be thrown server side on one field while the other ones succeed I've been…
I've never looked at graphene before (I've stopped spending time learning about each fad) but this really looks like it solves a real problem I've experienced. Definitely going to try it out.
Re: Ask HN: Were you happy moving your API from REST to GraphQL?
#24My company has been flirting with graphql. As a frontend dev, I had a positive experience with one service because the backend was far more willing to add new query options. The much publicized "only get what you ask for" part was largely irrelevant. I am, however, unsettled at the prospect is losing all the built in network and browser caching for idempotent calls (mostly I'm unsettled because no one else seems to s…
We found our sweet spot in terms of enabling the flexibility of front-end devs experimenting and defining their own queries while maintaining cacheability. During development, front-end devs use the Graphiql endpoint to play around with the data and figure out exactly what they want. Once that's settled, we turn it into a persisted query that is stored on the server and keyed by a unique ID that the client apps use in production instead of the raw GraphQL payload. You add a small amount of overhead for the coordination to create the persisted queries, but we're considering even building a self service process in the future.
Re: Ask HN: Were you happy moving your API from REST to GraphQL?
#25The problem with REST is largely the people who look at it blindly as "thing that makes the CRUD go" instead of as a methodology of how to effectively use HTTP verbs and designing URIs that make sense.
So I guess my question is, why would I use GraphQL over, say, the Swagger tool suite? Swagger and the OpenAPI spec defines a way of doing REST that best fits both what Roy Fielding meant for REST but also fits IDE and tool automation systems.
Re: Ask HN: Were you happy moving your API from REST to GraphQL?
#26Our front end engineers were extremely happy. Me personally, as a backend engineer, not as much, but it isn't too bad. There are some quirks (error handling), performance issues (e.g. fixing n+1 queries) and DOS concerns, but again, it isn't all that bad. (we're using rails/graphql-ruby on backend | react/relay on frontend)
I'd agree with this sentiment, on the backend, it isn't really easier and it's not really harder either. You end up dealing with different problems than with REST (as noted, different types of performance problems, more issues with error handling have been my biggest two).
The frontend developers see the biggest improvements, they have one endpoint to worry about and using a library like Apollo makes things really nice.
Overall, I think the improvements are worth it, especially when working on internal APIs.
Re: Ask HN: Were you happy moving your API from REST to GraphQL?
#27Yep, best decision. Both from a back-end experience (caching, performance, type safety) and front-end experience (flexible querying, great documentation, tracing, etc.)
Re: Ask HN: Were you happy moving your API from REST to GraphQL?
#28You're going to get responses from people who have invested a considerable amount of time in something they already had plans for (a "sunk cost") so I'm not sure you will get the sort of information you are after here.
Also, many people who have only recently adopted GraphQL, as it is relatively new. These people will not have the long-term experience necessary to assess GraphQL in hindsight.
There is an advantage to making technology decisions behind-the-curve, choosing mature, "battle-tested" technology, even if it means overlooking some known warts, and missing out on what's "hot". We can call this being a "late-adopter". I am most interested in N-years-later perspectives where N is around 3 or more.
Re: Ask HN: Were you happy moving your API from REST to GraphQL?
#29Absolutely. 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…
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.
Re: Ask HN: Were you happy moving your API from REST to GraphQL?
#30My company has been flirting with graphql. As a frontend dev, I had a positive experience with one service because the backend was far more willing to add new query options. The much publicized "only get what you ask for" part was largely irrelevant. I am, however, unsettled at the prospect is losing all the built in network and browser caching for idempotent calls (mostly I'm unsettled because no one else seems to s…
We found our sweet spot in terms of enabling the flexibility of front-end devs experimenting and defining their own queries while maintaining cacheability. During development, front-end devs use the Graphiql endpoint to play around with the data and figure out exactly what they want. Once that's settled, we turn it into a persisted query that is stored on the server and keyed by a unique ID that the client apps use i…
Is it fair to say that your system relies, more or less, upon one server change per client request change/new request type? Doesn't sound like a dealbreaker necessarily, but I thought this was a big part of the problem GraphQL was supposed to solve.