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

121–130 of 182 posts

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

#121

Post by schrockn »

Nick Schrock here, one of the GraphQL co-creators. I agree with a lot of the criticism in terms of the difficulty of implementing GraphQL backends. I think there's a big opportunity for folks to build vertically integrated toolkits that deal with N+1 issues, integrate DataLoader natively and so forth. Good versions of these would deal with a lot of issues described here in greenfield GraphQL backends. I talked about this at the GraphQL Europe keynote last month (https://www.youtube.com/watch?v=zMa8rfXI6MM).

Current greenfield implements are typically stacked on ORMs like Django and RoR, and the impedance mismatch is real. Personally I abide by the dictum that ORMS are "Vietnam of computer programming" and should be avoided at all costs for anything that will grow beyond a small app. GraphQL was not originally implemented on top of an ORM, but instead an object model built on key-value + edge store internal to Facebook.

In terms of other criticisms in this thread:

1) Exceptions: The default behavior in graphql-js (mimicked in other language implementations) of swallowing native exceptions by default was probably a mistake in hindsight. Whenever I've played with GraphQL using different toolsets the first thing I change is to add a wrapper function which checks for errors and then rethrows the initial exception that caused the GraphQL error for use in testing and CI/CD contexts.

2. Caching: Personally I've always been confused about the concern with leveraging HTTP-level caching. While a clever hack, with any real app with any sort of even mildly dynamic behavior you don't want to do this. Staleness will be interpreted, rightly, as bugs by your users. If you want to replicate the behavior the most straightforward way would be to use persisted queries (described here https://blog.apollographql.com/persisted-graphql-queries-wit...) combined with HTTP GETs. With persisted queries you can encode the entire request in the query string, which should get you the HTTP-level caching you want.

3. Docs: Quite confused about this one. While particular implementations of GraphQL can be problematic the documentation of the core language (which I am not responsible for) is superb. See http://graphql.org/ and https://www.howtographql.com/.

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

#122

Post by slow_donkey »

CGamesPlay wrote: post #91
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…

Why do you think it makes the most sense if “the backend and frontend teams don't like to talk to each other”, given that your biggest complaint seems to be “I don't want to spend time figuring out your database schema“? Aren’t you the frontend guy in this scenario, and not wanting/able to talk to the backend guys (the people who designed the database schema)?

The internal team would have a vested interest in introspecting the API but an end user (developer) would not.

But I actually found their graphql docs to be sensible? Not sure where the introspection comes into play

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

#123

Post by evilduck »

HEHENE wrote: post #82
OldSchoolJohnny wrote: post #21

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.

I'll be the voice of someone who is actively implementing GraphQL for the first time. We were mid-way through our project before realizing GraphQL might be a better fit for our use case so we paused for a week to play around with it and see if we could stand up something inside of our project that made sense. GraphQL felt very "plug and play" to us. Aside from having to re-work some validation to fit into GraphQL's i…

Could you share some info about your stack?

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

#124

Post by PhineasRex »

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 can implement cache ttls with an Apollo link. See https://github.com/kamilkisiela/apollo-link-maxage for an example.

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

#125

Post by filleokus »

syrusakbary wrote: post #96
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…

That's great feedback. I'm working on vastly improving exception reporting for the next version of Graphene :)

I just have to chime in and thank you for all the hard work with Graphene! You have almost become a meme at the office, we're looking at the latests RC's at the office and talking about what Syrus might be up to this time :-). As a side note, I'm happy to read about Quiver and I hope it becomes a sustainable business!

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

#126

Post by haney »

PhineasRex wrote: post #124
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 can implement cache ttls with an Apollo link. See https://github.com/kamilkisiela/apollo-link-maxage for an example.

Nice, I tried to hand roll something like this using link-state and my own renders but it didn't work well for me. I'll definitely check this out.

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

#127

Post by aclatuts »

I've been building a GraphQL only product for 1.5 years now. It was also the best scenario for graphQL because we were also rewriting an entire app from scratch.

For some background info this app has a huge feature set, low traffic, B2B, and at most 2 developers working on this app for about 1 year.

For the technical side I chose typescript from the back end and front end (Angular). This mean I could use the same typings from our ORM mongoose.

Very early on I was able to pick tooling that ending up being cutting edge compared to any other tool in any language, namely the tools where graphql-compose, grapqhl-compose-mongoose, and graphql-code-generator. In addition GraphQL lent itself pretty well to dependency injection on the server side.

It took about 6 months to get fully proficient, but it was completely worth it being able to use the same types for the front end and back end. GraphQL even made it possible to bootstrap types from mongoose into the server. A lot of time when dealing with 3rd party services I could copy the docs and turn it into types for the resolvers.

The biggest single benefit of it all was side stepping the middleware of Express. I didn't realize how awful express middleware are, because you can't really control the middleware chain very well. But the library with graphql-compose made chaining resolvers extremely precise, which was important.

Overall I love working with GraphQL but I realize that I probably could have done just as well with rest if the backend has decent middleware chaining i.e not express. For performance there is lots of options that are often built in like client caching, batched queries, whitelist queries, and persisted queries. It worked pretty well in a PWA too.

tl;dr

pros

- types everywhere!

- following the logic of any resolver is usually pretty straightforward.

- true middleware

- learned how to make good rest frameworks in the future.

cons

- hugely steep learning curve

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

#128

Post by smt88 »

andrewingram wrote: post #116
smt88 wrote: post #101

Earlier quoted context omitted.

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.

You don't know enough about my products to be so certain about my payment practices.

First of all, our backend is extremely complex and our frontend isn't. Our backend devs need a lot of legal and financial training. Other companies will have an inverse situation.

Second, there's a glut of frontend devs (at least when I look for them) because bootcamps seem to produce people who are better at frontend than backend.

And third, our frontend devs just don't have as much work to do, so they're idle a lot more often.

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

#129

Post by UncleEntity »

valw wrote: post #84

We migrated most of our backend (written in Clojure) from REST to GraphQL (actually a homemade alternative to GraphQL, but not relevant to this discussion). It went well, it greatly simplified both our backend and frontend code. The backend code got simpler and more stable because it no longer had to deal with "data packaging". The frontend code became more transparent, because you can now easily read what data gets…

> it repeated the SQL mistake of exposing a query language based on text, not data structures. Now we have to write queries as templates instead of assembling them programmatically.

Out of curiosity couldn't you just treat queries as a composable AST and "compile" the query text from that?

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

#130

Post by chillacy »

hrktb wrote: post #99
ilovecaching wrote: post #69

Earlier quoted context omitted.

Not really. With REST, the server dictates the minimum requirements of the client. In GraphQL, the client dictates its own requirements, and the server is able to respond with no more and no less than what the client requires. Also REST necessitates multiple HTTP queries to fetch multiple resources. This is not a requirement of GraphQL.

> the client dictates its own requirements, and the server is able to respond with no more and no less than what the client requires. The burden of dictating specs is just shifted around, and it seems the workload on the server side is bigger with h GraphQL (wider range of cases to handle). Am I missing something ? > REST necessitates multiple queries This is a self imposed limitation at best

Your graphql library will handle that for you. The server defines data as it knows, the client asks for data that it wants, and the library does the transform work.
Post reply on HN