No. It cold have been that Relay the JS graphql implementation we used was too heavy handed, but our team never fully grokked what was going on. It wound up introducing a bunch of friction into our workflow, and we ultimately wound up removing it.
Ask HN: Were you happy moving your API from REST to GraphQL?
51–60 of 182 posts
Re: Ask HN: Were you happy moving your API from REST to GraphQL?
#52We decided against it. We’re in a java backend and GraphQL in Java with ORM is considerably problematic when trying to create efficient resolvers. We simply ran into one hurdle after another and we were finding ourselves in diminishing returns. The concept is great, and if you write custom SQL queries for each resolver (if necessary), properly caching things that can be cached, and use the first class citizen program…
I think we will in time find someone cracking the code and creating a "requests" type library for graphql interaction. Either that or some graphql++ language will make things better. Maybe automatic/declarative DB integration? The concept of graphql is light years ahead of REST, but right now it basically requires server maintainers to implement half-baked query processors and solve problems that have been soloved since the 70s.
Re: Ask HN: Were you happy moving your API from REST to GraphQL?
#53Earlier quoted context omitted.
> Everything else is line noise. It's always weird to see this type of thing on HN. How anyone can call the way the web works "line noise" is baffling to me.
Fundamentals vs. changing tech. "Idempotency" as a concept is fundamental. Which header means what for some cache layer is not. REST unavoidably has a lot of things in it that are changing tech. (Nominally, it has a lot of fundamentals in it too, but per the other REST discussion on the homepage, which fundamentals it encompasses seems to vary on a person-by-person basis.)
Thanks, said it better than I could.
Re: Ask HN: Were you happy moving your API from REST to GraphQL?
#54Absolutely. 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…
What is a red haired resource?
Think "red-headed stepchild". The weird ones.
Re: Ask HN: Were you happy moving your API from REST to GraphQL?
#55Mostly, 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.
Protip: ignore the docs on the website, use the docs on the github package / in the examples instead. They're much better!
Re: Ask HN: Were you happy moving your API from REST to GraphQL?
#56Absolutely. 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…
"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.
Re: Ask HN: Were you happy moving your API from REST to GraphQL?
#57I had hoped that GraphQL would come along with a solution for 'live queries' - alas that seems to still be on the drawing board. Really looking forward to when 'send me a list, and any changes to that list, and merge them together' is a problem I don't have to put any thought into solving.
Re: Ask HN: Were you happy moving your API from REST to GraphQL?
#58Absolutely. 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…
What is a red haired resource?
Entities that one doesn't normally think of as a resource, such as an algorithm.
Re: Ask HN: Were you happy moving your API from REST to GraphQL?
#59We decided against it. We’re in a java backend and GraphQL in Java with ORM is considerably problematic when trying to create efficient resolvers. We simply ran into one hurdle after another and we were finding ourselves in diminishing returns. The concept is great, and if you write custom SQL queries for each resolver (if necessary), properly caching things that can be cached, and use the first class citizen program…
It's not impossible in Java but it does require a strong grasp of graphql-java's execution model and the DataFetchingEnvironment and associated classes.
We accomplish something similar to what you desire when querying our time series database via GraphQL.
The big difference between Java and Javascript when it comes to GraphQL is the amount of noise, tutorials and examples on the Javascript side far outweigh other options right now.
Javascript may be the "happy" path for now but I do hope that we see continued investment in Java/Scala/Ruby/Python/.NET etc as those implementations have the opportunity to be better architected and more performant that the reference JS implementation. The reference implementation uses a very simplistic execution model which for now has been copied almost verbatim into other languages but there is great potential for a proper query planner and optimisation layer at the GraphQL layer.
Disclaimer: I work at MDG on Apollo Engine (the backend of which is Kotlin utilising graphql-java).
Re: Ask HN: Were you happy moving your API from REST to GraphQL?
#60Earlier quoted context omitted.
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 wel…
What language/framework was this being implemented on? If you dont mind me asking.
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.