Hacker News Reader

Comment by RyanShook | Hacker News Reader

What is the consensus on GraphQL? Is it really killing the Rest API or is that more hype?

GraphQL is awesome. As a consumer of a graphql api, it's a no-brainer, it's so much easier/faster/flexible than REST (obv. a well designed rest server/client can be fast and flexible and get caching right, but that is not typically the case (whereas caching and what not is typically built in to the graphql clients)).

I think the server-side of graphql is holding it back right now. It's harder to get started building a graphql server than a rest server. Another issue I see is lots of graphql servers are just proxying an existing REST API which is unfortunate since you're just adding latency and complexity (for a rather significant front-end development boost).

My experience trying to build out the server side backend in GraphQL for various features was miserable:

* you are adding an additional abstraction layer on top of your data store (in our case, SQL), with significant cost in complexity and speed. This was for queries that served many thousands (or more) of requests a day, btw, so maybe it would be fine for apps w/ just tens or hundreds of users.

* trying to get any complex queries performant was _very_ difficult. We knew how to avoid n+1's w/ SQL and our ORM, but doing so with GraphQL loaders was very difficult and required some very intense promise-based code that was incredibly hard to debug or understand.

* the abstractions felt all wrong - it often felt like our the GraphQL loading layer was completely disjoint from the existing domain model. Building out the GraphQL layer often came at the expense of the domain layer -- maybe this was due to our own inexperience in mixing the two ? Anyway, it felt similar to how impossible it felt to build a decent domain model back in the days of Javabean / EJB frameworks.

That was my experience around a year or year and a half ago, anyways. I definitely see the value in the declarative nature of GraphQL for client usage, but the cost on the server side felt _very high_ to make it a reality.

I didn't have that experience. Plus you can always have both REST and GraphQL. Your GraphQL server can simply call your REST endpoints. If you already have a REST API built it's not that much work to set up a GraphQL gateway.

I've heard GraphQL is a better match for graph databases. I wonder if the issues you encountered might be a result of that mismatch?

Not true per se, the name GraphQL is you are conceptually thinking about your data in terms of a graph. The underlying data store could be parsing a CSV file to resolve your data & graphQL still adds immense value.

It’s miserable when your starting point is the default js implementation for the executor, but if you write your own executor you have a lot of freedom to do cool stuff.

I’ve built a graphql interface here https://subzero.cloud on top of the powerful rest interface of https://postgrest.com which in turn sits on top of postgresql.

The end result is you define your tables/views/functions in sql and on the other end you get rest+graphql api to your data

> We knew how to avoid n+1's w/ SQL

You can simply create one graphQL field corresponding to each REST end point you have now, and have it do an SQL query in the resolver.

> you are adding an additional abstraction layer on top of your data store

yes that is one of the main benefits (it allows you to coalesce data from multiple data stores).

Having used graphql in production environments for about 6 months now, I would say that it is amazing and should be a first option for new APIs. The big selling points for me are:

1) self-documenting and explorable API (via GraphiQL interface) mean I don't have to ask backend if this or that value has been put in there.

2) expensive-to-fetch attributes returned in a query are only fetched/calculated if asked for. This means we don't need to split off logically similar queries into two REST endpoints to optimize the site

3) strict type and value checking mean I will always get back what I expect to get back. Attributes can be deprecated and throw a warning if I ask for them. If I ask for an attribute that is outside the spec it will give me an error. This is great for code maintainability.

4) frontend and backend can communicate more effectively with a standard contract. Building a react frontend with Apollo made me constantly question why I was getting paid so much to do what I did, it was that easy.

5) Implementation specific, but Apollo is really amazing and handles caching, dependent queries (I can ask a set of queries to refetch if I perform an update), and is dead simple to create a frontend around.

I haven't played with graphql much yet but one thing that really struck me most was that it's possible for a single graphql query to make multiple queries to database. I read that dataloader helps in this case, is this similar to what you mentioned in #5?

#5 was just about client caching. Yes it is true a naive graphql implementation can make multiple db queries which can create a performance concern, but there are ways to mitigate it with various tools, or with clever structuring of the schema.

Its an artifact of being able to define an individual, independent resolver for each attribute. The advantage of this though is that it makes it easy to stitch together multiple data sources into one schema, so GraphQL shines especially as a wrapper, or as a query layer on top of a non-relational data store, like Mongo or Dynamo

Apollo client is great in many ways. Where I'm having trouble is as my React app grows I need to update the local cache when I add or delete items. You have to tell Apollo what to do and it becomes more complex as the app grows. Almost like you're mirroring your db on the client.

You could just always tell it to re-fetch, effectively disabling caching.

> Almost like you're mirroring your db on the client.

Well that was the goal of mini-mongo in Meteor, before they ramped down development to work on Apollo. I think mirroring the db on the client is sort of the goal.

I've really come to enjoy using it, especially with Apollo and Absinthe. I now make client-side changes all the time without having to touch the server at all.

It did take me some time to wrap my head around the details, but the ability to project many of the requested fields more-or-less directly into the SQL SELECT, and being able to batch things together to turn 1+N queries into 1 has made writing resolvers a total breeze. Apollo and Absinthe are some of the most polished pieces of OSS I've ever worked with – well worth the extra boilerplate for non-trivial projects.

Love GraphQL, the more I use it the more I like it. Githubs v4 api[1] is looking slick and a good example of how nice GraphQL can be compared to REST.

[1] https://developer.github.com/v4/

Not saying anything about GraphQL in particular as I have almost no experience with it in practice, but there are cases where REST is simply unbeatable, especially if you're very comfortable with it: Simple APIs, encapsulating simple data models. Often you can get away with using the simplest and most common (client- and server-side) frameworks available to implement those, and that's all that's needed.

I'm confused -- doesn't GraphQL need Rest APIs (or APIs in general) to work? It's just kind of a wrapper -- unless I'm mistaken in my understanding.

No. A GraphQL server is agnostic to how your data is fetched. You could pull the data from a REST endpoint, or put the SQL query to the db right there in your resolver on the GraphQL server itself.

After 1.5 years, I can tell that using GraphQL compared to REST/Redux feels like using SQL instead of implementing your own database.

REST and GraphQL have slightly different use cases. REST is simpler, both in concept and implementation than GraphQL. GraphQL offers more flexibility in exchange for that added complexity. GraphQL puts more of the burden on the front-end/client-side code to define the data they want, which is a good fit for services that have many different consumer platforms that require different data (web, mobile, etc), or when the scope of the data that should be returned is very context-specific (e.g. I only need preview-size images for this view, but I need a large images and more metadata for another, and some other requirements for a third).

It's great for consumers of APIs, especially focused on web frontends and mobile apps. That's about it.

Anyone offering APIs can help their users but like all things it takes effort to do and usually isn't worth it unless it's a very big service with lots of users.

If you control both the client and the server then there's little, if any, benefit over REST.

For me, GraphQL is superb for GET requests. I use REST for everything else.

My 2c: I really like it to fetch data on the client side, works well with component based frameworks. But data mutations are a mess and lots of stuff you have to figure out yourself on the server side.

Think they'll live together happily forever... GraphQL will grow faster short term I think.

Reply on news.ycombinator.com