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

151–160 of 182 posts

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

#151

Post by pandeiro »

smt88 wrote: post #102
pandeiro wrote: post #89

Earlier quoted context omitted.

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.

How does the complexity bite you? Large files, bad error messages, bugs? Something else?

Limited error handling mechanism in Apollo and our backend GraphQL library means I can't use then/catch to reliably handle both network and server errors. Apollo also hijacks state management and somehow decides when to fetch over the network or render a cached response, with no particular logic I can deduce or find documentation for. Then there's the thousand lines of repetitive query code that is a joy to read/write/manage.

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

#152

Post by pandeiro »

ericcoleman wrote: post #111
pandeiro wrote: post #89

Earlier quoted context omitted.

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.

Right, then you basically lose caching, since the everything's-a-POST requests would go to the wire every time. Not that I haven't considered making that trade-off.

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

#153

Post by naasking »

CuriousSkeptic wrote: post #117
Zyst wrote: post #73

Earlier quoted context omitted.

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

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

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

#154

Post by BerislavLopac »

elliotec wrote: post #150
BerislavLopac wrote: post #142

Earlier quoted context omitted.

I'm not quite sure what does the database schemas have to do with the front-end queries...

In this case OP is talking about the GraphQL schemas, not the DB.

I'm not sure which OP do you mean? The parent mentions "SQL experience", the grandparent is ambiguous, and the GGP explicitly mentions "database schema".

If by OP you mean the original article, I completely agree with you; my comment was directed to its ancestors.

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

#155

Post by nailer »

ericcoleman wrote: post #111
pandeiro wrote: post #89

Earlier quoted context omitted.

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.

You shouldn't be using fetch directly accoriding to it's creator anyway - use a high level HTTP client which handles MIME types, query string encoding, etc.

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

#156

Post by alexchamberlain »

t_fatus wrote: post #66
t_fatus wrote: post #63

I'd like to add that correctly designed resolvers allow you: - to control very easily who can fetch what where it's fetched (permissions) - to fetch nested data when you need it without writing serializers - to help your frontend team find what they are looking for without asking the backend team everytime - mutations are a huge plus when it comes to standardization of your API too FYI we're using it in production ov…

One important thing to note: performance-wise, both in front-end when used with apollo, and in backend (you need to handle nested queries smartly) a good implementation of a REST api would probably be faster / lighter, but it should be largely enough for any web-app / web-service used by human beings ;)

Citation needed; what is your evidence for such an assertion?

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

#157

Post by nicwolff »

You don't have to "move" to reap GraphQL's benefits – you can just add a GraphQL layer.

I'm backend Systems Architect at a big publishing company, and my current primary project is an aggregating caching GraphQL proxy for our REST microservices.

Our front ends were making too many calls to the REST APIs, so we went overboard embedding related resources – and now they're getting too much unneeded data back, and cache invalidation is a nightmare. Sounds familiar, probably!

So we're building a GraphQL service that stitches those REST APIs together to let the caller request exactly the fields they need, from any API's resource. By caching individual resources, rather than nested multi-resource serializations, we can invalidate easily by UUID on change events – so cache TTLs can be long – and the GraphQL API's field resolvers can assemble complex responses with a few fast Redis MGETs, which are batched by DataLoaders.

This also gives us a place to centralize business logic, rather than having each front end service reimplement field formatting, resource transforms, &c. Since the REST APIs remain available as the source of truth, existing services can migrate to the GraphQL proxy at their own pace, which we hope will be an easy sell since it's so much faster.

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

#158

Post by ilovecaching »

wuliwong wrote: post #108
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…

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

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

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

#159

Post by jupp0r »

pandeiro wrote: post #151
smt88 wrote: post #102

Earlier quoted context omitted.

How does the complexity bite you? Large files, bad error messages, bugs? Something else?

Limited error handling mechanism in Apollo and our backend GraphQL library means I can't use then/catch to reliably handle both network and server errors. Apollo also hijacks state management and somehow decides when to fetch over the network or render a cached response, with no particular logic I can deduce or find documentation for. Then there's the thousand lines of repetitive query code that is a joy to read/writ…

Sounds like the problem is with your client/server library choices and not with GraphQL as a concept. Your original comment implied the latter.

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

#160

Post by sbinthree »

Much prefer REST assuming nested documents are aggregated by default into the parent. If it's just an HTTP RDB client like some can be then not so much. Less data on wire doesn't matter for server to server communication. I can see it for APIs whose sole purpose is low bandwidth client apps.
Post reply on HN