Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Were you happy moving your API from REST to GraphQL?

news.ycombinator.com

Post reply on HN
Print view View original

41–50 of 182 posts

Re: Ask HN: Were you happy moving your API from REST to GraphQL?

#41

Post by krainboltgreene »

heavenlyhash wrote: post #4

Yes. (Mostly.) REST semantics are a distraction. The best possible outcome of REST is when developers are encouraged to consider the concept of "idempotency" when they stumble upon the technical definition of the "PUT" verb. Everything else is line noise. GraphQL has a schema with types. It makes it very straightforward and approachable for all developers to reason about what an API should deliver up-front, and also…

> 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.

Re: Ask HN: Were you happy moving your API from REST to GraphQL?

#42

Post by vinayan3 »

haney wrote: post #10

Mostly, 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…

> My biggest complaint has been "lost" exceptions and caching.

This is quite annoying because the server never throws a 500 error so the normal logging doens't kick in.

Re: Ask HN: Were you happy moving your API from REST to GraphQL?

#44

Post by jerf »

krainboltgreene wrote: post #38
ilovecaching wrote: post #22

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…

> 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.

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?

Re: Ask HN: Were you happy moving your API from REST to GraphQL?

#45

Post by jerf »

krainboltgreene wrote: post #41
heavenlyhash wrote: post #4

Yes. (Mostly.) REST semantics are a distraction. The best possible outcome of REST is when developers are encouraged to consider the concept of "idempotency" when they stumble upon the technical definition of the "PUT" verb. Everything else is line noise. GraphQL has a schema with types. It makes it very straightforward and approachable for all developers to reason about what an API should deliver up-front, and also…

> 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.)

Re: Ask HN: Were you happy moving your API from REST to GraphQL?

#46

Post by ulkesh »

We 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 programming language (JavaScript), then it seems GraphQL works wonderfully.

Trying to fit it into an existing ORM paradigm with respect to complex sub-collections, lazy loading, and efficient database querying, it just didn’t work out for us.

Re: Ask HN: Were you happy moving your API from REST to GraphQL?

#48

Post by filleokus »

haney wrote: post #10

Mostly, 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…

Regarding monitoring, I would recommend to check out Apollo Engine if you haven't already. Basically middleware on the server side that injects error and performance info into the extensions object of the response which is then sent to them and presented in a nice UI.

Re: Ask HN: Were you happy moving your API from REST to GraphQL?

#49

Post by dmix »

ilovecaching wrote: post #29
ilovecaching wrote: post #22

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…

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.

Re: Ask HN: Were you happy moving your API from REST to GraphQL?

#50

Post by dugword »

ilovecaching wrote: post #22

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…

What is a red haired resource?
Post reply on HN