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

The main disappointment is that input types are not nearly as expressive as output types.

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 easy to reason about what is and is not a breaking change. Automatic validation of queries against the schema also saves massive amounts of time in writing validation logic.

There are still things that could be better with GraphQL. The query language is... interesting. The whole thing is still very client-server asymmetric -- look at a client query syntax versus the schema syntax you'll use on the server side for three seconds and you'll immediately and viscerally know what I mean -- and that strikes me as disappointing in this age. It's still very easy for developers to fall into mental quicksand which causes them to make many individual requests even when GraphQL would let them batch things up into one. And so on.

But overall: yes, working on a GraphQL stack is an awesome experience compared to going it alone with REST and JSON and crossed fingers.

I don't think it is either of. I use both. In the same API. The two are largely compatible.

All REST APIs can be modeled in RPC style APIs and that's no different with GraphQL.

I've done APIs where I have a GraphQL facade in front of REST and REST Facades infront of GraphQL by having all my REST endpoints be two lines

1. Graph QL query

2. Format result as REST

That first like maps to a graphQL query and the second one can be standardized for all your REST endpoints.

I tend to like REST in-front of GraphQL better since it allows for some performance optimizations when you know ahead of time all the data you need to grab.

And since GraphQL can be mapped to classes you could also just skip the GraphQL query compile and use the classes directly from your REST with only a few more lines of code.

Overall I like GraphQL a lot because it allows the frontend to make less round trips to the server and makes it easier to exclude data you don't want (which helps when data is large). Json:API tries to solve some of this with includes, related, and fields but it doesn't quite allow as much expressiveness as GraphQL.

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 plagued with hard to monitor/find errors. I ended up writing a shim to parse the response in an attempt to get more insight into #errors / fields (this has also been really helpful for monitoring slow queries in new relic since all requests go to the same endpoint which breaks a ton of APM monitoring).

My other issue has been around caching, in apollo there are ways to say "don't use the cache for this request", but it's not to give an object a cache ttl. My app allows users to search for events that are happening near them right now, and I've run into several issues where apollo decided that an event from yesterday should be added to a result. It happened frequently enough even with queries that included times as an argument that I ended up basically implementing a "middleware" between what apollo gives back and the component, which felt really ugly.