6 ms·

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

Siilwyn 9y ago
Think they'll live together happily forever... GraphQL will grow faster short term I think.
kabes 9y ago
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.
seeekr 9y ago
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.
xiaomai 9y ago
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).
andjd 9y ago
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).
shusson 9y ago
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/ https://developer.github.com/v4/
skosch 9y ago
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.
manigandham 9y ago
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.
ctulek 9y ago
After 1.5 years, I can tell that using GraphQL compared to REST/Redux feels like using SQL instead of implementing your own database.
mmanfrin 9y ago
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.
- chrisco255 9y ago
  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.
headcanon 9y ago
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.
- shriek 9y ago
  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?
  - headcanon 9y ago
    #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
- Blackstone4 9y ago
  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.
rsanheim 9y ago
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.
- chrisco255 9y ago
  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.
- faitswulff 9y ago
  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?
  - joshribakoff 9y ago
    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.
- 9y ago
NetOpWibby 9y ago
For me, GraphQL is superb for GET requests. I use REST for everything else.

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

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.

seeekr 9y ago

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.

xiaomai 9y ago

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

andjd 9y ago

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

shusson 9y ago

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/ https://developer.github.com/v4/

skosch 9y ago

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.

manigandham 9y ago

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.

ctulek 9y ago

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

mmanfrin 9y ago

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.

chrisco255 9y ago
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.

headcanon 9y ago

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.

shriek 9y ago
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?
- headcanon 9y ago
  #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
Blackstone4 9y ago
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.

rsanheim 9y ago

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.

chrisco255 9y ago
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.
faitswulff 9y ago
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?
- joshribakoff 9y ago
  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.
9y ago

NetOpWibby 9y ago

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