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

111–120 of 182 posts

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

#111

Post by ericcoleman »

pandeiro wrote: post #89
Androider wrote: post #78

As a consumer of APIs I vastly prefer REST APIs. In my opinion, GraphQL moves too much of the burden to the user of the API. It makes most sense if the data is highly dynamic, you have a mobile app and every call is expensive, or (and this seems more common) the backend and frontend teams don't like to talk to each other. As a user, I just want to GET /foo, with a good old API token I pasted from your dev docs, and m…

I How I _wish_ I could nope the hell out of our GraphQL dependency, for the reasons listed and for the frighteningly complex client libs we have to use to consume it, rather than straight up ajax/fetch.

You don't have to use anything other than `fetch` to consume a graphql API.

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

#112

Post by sgrove »

Androider wrote: post #78

As a consumer of APIs I vastly prefer REST APIs. In my opinion, GraphQL moves too much of the burden to the user of the API. It makes most sense if the data is highly dynamic, you have a mobile app and every call is expensive, or (and this seems more common) the backend and frontend teams don't like to talk to each other. As a user, I just want to GET /foo, with a good old API token I pasted from your dev docs, and m…

Interesting! Were you doing a server-to-github integration, or were you using the GraphQL API directly from the frontend?

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

#113

Post by haney »

filleokus wrote: post #48
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.

I’ve played with it a little, and I may resort to creating a proxy node app that reads through to the python app exclusively so I can get better monitoring.

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

#114

Post by ergothus »

smt88 wrote: post #101
Androider wrote: post #78

As a consumer of APIs I vastly prefer REST APIs. In my opinion, GraphQL moves too much of the burden to the user of the API. It makes most sense if the data is highly dynamic, you have a mobile app and every call is expensive, or (and this seems more common) the backend and frontend teams don't like to talk to each other. As a user, I just want to GET /foo, with a good old API token I pasted from your dev docs, and m…

As a manager/business owner, I like GraphQL because it shifts the burden to the API consumer. That consumer, for us, is a front-end resource who is sometimes less expensive but very often less busy than our backend team. That's obviously not the same formula for every company. I'm just offering it as a potential counterpoint.

This is a common swing point though:

PM: Make this change to the site

Backend: that would take 2 weeks to make sure it doesn't break anything

Frontend: That's a tiny change! I can do it in 2 hours

Frontend makes the change. Along with the next several. Overtime, the backend team uses the lessened pressure to overhaul/replace/refactor to decrease the complexity. Meanwhile, Frontend is starting to accumulate a collection of unrelated exceptions to the "normal" flow to meet demands. Eventually....

PM: Make this change to the site

Frontend: Um...that would risk all sorts of complications. Consider it a few weeks to make sure it doesn't break anything

Backend: That's a straightforward change, I can do it in 2 hours

And the pendulum starts to swing in the opposite direction...

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

#115

Post by MattyRad »

Androider wrote: post #78

As a consumer of APIs I vastly prefer REST APIs. In my opinion, GraphQL moves too much of the burden to the user of the API. It makes most sense if the data is highly dynamic, you have a mobile app and every call is expensive, or (and this seems more common) the backend and frontend teams don't like to talk to each other. As a user, I just want to GET /foo, with a good old API token I pasted from your dev docs, and m…

This is my experience as well. We briefly worked with GraphQL for one of our smaller projects. One of the biggest shortcomings of the API we created was that there was an incredibly large learning curve for teams/people not interested in using GraphQL. Instead of using the sensible features of GraphQL queries, the other team consuming our API were writing the most verbose queries they possibly could, not utilizing any of the nice convenience operations that GraphQL offers.

They were no doubt frustrated with what they thought was a needless hassle compared to REST, and I myself found a lot of the query building pretty tedious.

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

#116

Post by andrewingram »

smt88 wrote: post #101
Androider wrote: post #78

As a consumer of APIs I vastly prefer REST APIs. In my opinion, GraphQL moves too much of the burden to the user of the API. It makes most sense if the data is highly dynamic, you have a mobile app and every call is expensive, or (and this seems more common) the backend and frontend teams don't like to talk to each other. As a user, I just want to GET /foo, with a good old API token I pasted from your dev docs, and m…

As a manager/business owner, I like GraphQL because it shifts the burden to the API consumer. That consumer, for us, is a front-end resource who is sometimes less expensive but very often less busy than our backend team. That's obviously not the same formula for every company. I'm just offering it as a potential counterpoint.

If a frontend employee isn't earning a comparable salary to a backend employee, you're either not hiring people of equivalent skillset, or you're underpaying your frontend people.

Where the GraphQL burden lies is largely due to who is considered to be its product owner. This varies significantly depending on whether it's an API for first or third parties.

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

#117

Post by CuriousSkeptic »

Zyst wrote: post #73
xtrapolate wrote: post #56

Earlier quoted context omitted.

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

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

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.

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

#118

Post by haney »

arnorhs wrote: post #33
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…

you should take a look at the caching policies (fetch policy) apollo client provides as well as the error policy. neither are easy to find for the error policy, you basically control the behavior (for each client instance or each request) when a request is considered failed. none, ignore and all. [1] fetch policy allows you immense control over caching. this all depends on what you're doing but in some instances it c…

So I understand that I can use the cache, not use the cache, or use the cache and always go over network for the entire request but that's all client side. GraphQL in general lacks a good answer for object level caching (so in my case I just filter things out before they make it to the component). It also lacks a solution for the server to indicate to the client how long something should be cached (like you would with cache headers or Etags)

It's just really annoying that I have a ton of queries that return lists of objects, where each object has an easily known expiration time, and there's no way to say, "cache this result but remove the elements that have expired". I can't even say, "cache this list until X time", which would be very easy in a RESTful environment. I know there are extensions to support caching but none of them are universal yet. I'm hopeful that the community will land on an answer for object level cache expiration.

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

#119

Post by [deleted] »

Androider wrote: post #78

As a consumer of APIs I vastly prefer REST APIs. In my opinion, GraphQL moves too much of the burden to the user of the API. It makes most sense if the data is highly dynamic, you have a mobile app and every call is expensive, or (and this seems more common) the backend and frontend teams don't like to talk to each other. As a user, I just want to GET /foo, with a good old API token I pasted from your dev docs, and m…

[deleted]
Post reply on HN