6 ms·

I've looked at GraphQL a number of times. Does anyone have any practical examples of integrating it with backend(s), APIs, and/or specific databases? So inste

I've looked at GraphQL a number of times. Does anyone have any practical examples of integrating it with backend(s), APIs, and/or specific databases? So instead of "we use GraphQL, much love" + basic example and how it looks on React - a "here's how we take that structure and resolve it and return it." Because that structure looks amazingly sweet - but if in the background it's requiring circles of work, work and rework... Anyhow, maybe I just don't understand it enough.

zrail 9y ago
If you're using Rails there's a very good gem with some great examples: https://github.com/rmosolgo/graphql-ruby https://github.com/rmosolgo/graphql-ruby Ryan supports development with a pro version that has a bunch of neat features, including built-in support for a handful of common authorization frameworks. I highly recommend it.
tylerpachal 9y ago
We are using the Sangria[0] framework with a Play[1] app. Sangria does all of the GQL related stuff and Play dos the usual server stuff. Sangria's documentation is quite good, but the part that answers your question will be in the "Schema Definition"[2] section, which is where you describe the schema of your graph, and how each field is resolved. [0] http://sangria-graphql.org http://sangria-graphql.org [1] https://www.playframework.com https://www.playframework.com [2] http://sangria-graphql.org/learn/#schema-definition http://sangria-graphql.org/learn/#schema-definition
ruslan_talpa 9y ago
You've hit a (pain) point. While graphql reduces the amount of trips to the backend for the browser, those round trips get pushed down to a lower level, between backend and db. The reference graphql-js implementation, while at first looks so easy, you just write a resolver for a field, makes it oh so easy to have terrible n+1 problems. dataloader helps a bit but it's not as optimal as it can be. You need to be very careful. To be optimal, you'll basically need to write very complex resolvers that inspect the AST themselves and fetch the data optimally which at that point is almost as writing your custom execution module. That is basically what i did, custom execution module to translate a graphql request to a single sql query (https://subzero.cloud/ https://subzero.cloud/)
- scottmf 9y ago
  Which n+1 problems doesn't dataloader solve?
  - foota 9y ago
    You don't have to worry so much about n+1 (once you're using dataloader) as much as you do deeply nested queries, or queries that run against a large number of datatypes.
    - ruslan_talpa 9y ago
      i am not sure i follow, the deeper the query or bigger the returned dataset, the worse the performance of a dataloader type solution (see my other comment).
      - foota 9y ago
        We're agreeing here, I think. I'm saying that after taking care of the n+1 problem by using dataloader, you still have to worry about deeply nested queries.
        andrewingram 9y ago
        This is true, but most complex UIs tends to result in queries that spread wide rather than deep. It takes some deliberate contrivance or fairly unusual real-world cases to get to more than 3-4 levels of nested relationships, and this is often the point at which you'd be thinking to deferred/lazy loading in the client anyway. I've spent a significant amount of time over the last year or so optimizing GraphQL servers built on domain-driven services (i.e. joins aren't an option) and managed to get to equal (or very marginally worse) performance to existing handcrafted endpoints that returned equivalent data (it was possible to build the same UI, even though the payloads weren't identical). There are areas where GraphQL is inherently inefficient (trying to work on ways to mitigate these issues), but the reality is that deeply-nested UI appears to be less of a problem than I originally thought it would be.
thomasfoster96 9y ago
I strongly suggest that you look at Apollo's GraphQL offerings. My 'aha' moment with GraphQL came while reading the docs for their GraphQL server[0]. IMHO Relay doesn't make a lot of sense. Apollo Client [1] has a much better feature set for most use cases, doesn't need React and is better documented. [0] http://dev.apollodata.com/tools/graphql-tools/resolvers.html http://dev.apollodata.com/tools/graphql-tools/resolvers.html [1] http://dev.apollodata.com/core/ http://dev.apollodata.com/core/
- fishnchips 9y ago
  +1 to that. I'm working on a (mostly) GraphQL application with a Rails backend and a React frontend with a touch of Redux. I really wanted to like Relay but the documentation was lacking (I suspect that a major API change is to blame) and the amount of boilerplate is prohibitive. On the other hand Apollo Client is straightforward, framework agnostic with great React bindings. As a web development veteran I feel that I've never been as productive as with this particular stack.
- andrewingram 9y ago
  Used Relay Classic for a year and a half, been using Relay Modern for a month or so. You are absolutely right, the documentation situation is terrible. The fact that the new mutation API has practically zero documentation is troubling. I've been sticking with it though, and I am enjoying it. I feel like I have a greater grasp of what's going to be executed and when than I ever did with Relay Classic, and the file size + performance improvements are worth the cost of admission in my mind.
  - thomasfoster96 9y ago
    Have you been using normal Relay or one of the forks/modified versions that supports server-side rendering? The fact that Apollo Client supports server-side rendering out of the box was a big plus for me. > the file size + performance improvements are worth the cost of admission in my mind. Is this Relay Classic vs Relay Modern or Relay vs Apollo?
    - 9y ago
zackify 9y ago
I agree. All of the examples are trivial. There are a lot of nice things about graphql. Yet there are a lot of problems and annoyances other things don’t have such as query batching. Even authorizing certain graphql queries / mutations is not a trivial thing. I’ve been able to solve a couple of these things in my own app, but it’s just not something built into the spec.
djmashko2 9y ago
This is definitely a real problem and we just launched a website yesterday which we hope will grow into a resource for this kind of more advanced content: http://www.graphql.com/guides/ http://www.graphql.com/guides/ You can also see a lot of examples of GraphQL server code for JS here: https://github.com/apollographql/launchpad https://github.com/apollographql/launchpad It includes connecting to DBs, APIs, etc.
andrewingram 9y ago
Here's a high-level article about performance in general, but it shows how a UI and query could map to (for example) a function-driven API (this could be local to the server or remote): https://dev-blog.apollodata.com/optimizing-your-graphql-request-waterfalls-7c3f3360b051 https://dev-blog.apollodata.com/optimizing-your-graphql-requ... Examples more specific to a particular backend technology feel redundant because my assumption is that once you're in the land of calling functions, we don't need to hold your hands anymore. The most important thing is to be aware of the different batching strategies that are available to you in each GraphQL implementation because I believe this is the most critical part of getting a GraphQL server to perform well with anything other than a graph database.
- ruslan_talpa 9y ago
  assuming all your data comes form the same database, you can reduce one graphql query to one sql query that you can run on PostgreSQL (which is not a graph database). So batching is not the only option (and probably not the best)
mrskitch 9y ago
I've written a fair bit about it. We use it at AppNexus internally for our UI's, and it simply maps back to a REST API. Since each API has its quirks and oddities, it's a nice abstraction layer for consistency. http://joelgriffith.net/lessons-learned-wrapping-a-rest-api-with-graphql/ http://joelgriffith.net/lessons-learned-wrapping-a-rest-api-... For starters
fiatjaf 9y ago
As a standalone all-by-myself indie developer I was skeptical of GraphQL when it first appeared, but later I discovered it is much easier to develop APIs for my own consumption with GraphQL. The basic GraphQL boilerplate seems bad, but is actually fun to write and makes total sense. And once you have the structure in place it is super easy to add functionality. Plus bonuses if you have more than one database or are mixing data from your database and external APIs in your backend responses. Please try it for a small project, it is unbelievable, but you'll probably enjoy it. (For the record: I've just used https://github.com/graphql-go/graphql https://github.com/graphql-go/graphql and Lokka on the client, because it is simple and does nothing fancy, it's a thin wrapper over XHR, I think.)
- pier25 9y ago
  > Plus bonuses if you have more than one database or are mixing data from your database and external APIs in your backend responses. You can easily do that with a RESTful API too.
  - fiatjaf 9y ago
    You can do anything with any programming language, framework or design pattern.
    - pier25 9y ago
      Yes, hence it's not a bonus.
pier25 9y ago
On the server side it's very similar to REST. You define your types in a schema file, and then write functions that go fetch the data for each type. These functions are called resolvers. For example you have a Product type, and then write the resolver function that queries the database and/or another API. When you have the data, you pass it back to the client via Apollo or Relay. The big advantage over REST is that the client can define what data it wants and how it wants it. If you are full stack dev this isn't such a great advantage, but for bigger projects where front/back are spread among many engineers this can be an advantage. Also, since the schema defines the types, your API is almost self documented so to speak. The big disadvantage is authentication and authorization. We kept using REST for authentication, and we couldn't find any ready made solution for role based authorization like you have in Express, Hapi, etc. I think a combination of REST and GraphQL is the better approach.
ohthehugemanate 9y ago
We're using graphql in front of a Drupal 8 data engine, with a variety of other data sources behind that. It's also for a publishing company, that has a bunch of different front end sites all served from the same content store... But with separate development groups. We're using the youshido graphql library for it... Though now that development is further along, I wish we'd chosen the webonyx one. A good GraphQL backend resolves the graph into query results efficiently, rather than just field by field. But that does take a but of getting used to....

zrail 9y ago

If you're using Rails there's a very good gem with some great examples: https://github.com/rmosolgo/graphql-ruby https://github.com/rmosolgo/graphql-ruby Ryan supports development with a pro version that has a bunch of neat features, including built-in support for a handful of common authorization frameworks. I highly recommend it.

tylerpachal 9y ago

We are using the Sangria[0] framework with a Play[1] app. Sangria does all of the GQL related stuff and Play dos the usual server stuff. Sangria's documentation is quite good, but the part that answers your question will be in the "Schema Definition"[2] section, which is where you describe the schema of your graph, and how each field is resolved. [0] http://sangria-graphql.org http://sangria-graphql.org [1] https://www.playframework.com https://www.playframework.com [2] http://sangria-graphql.org/learn/#schema-definition http://sangria-graphql.org/learn/#schema-definition

ruslan_talpa 9y ago

You've hit a (pain) point. While graphql reduces the amount of trips to the backend for the browser, those round trips get pushed down to a lower level, between backend and db. The reference graphql-js implementation, while at first looks so easy, you just write a resolver for a field, makes it oh so easy to have terrible n+1 problems. dataloader helps a bit but it's not as optimal as it can be. You need to be very careful. To be optimal, you'll basically need to write very complex resolvers that inspect the AST themselves and fetch the data optimally which at that point is almost as writing your custom execution module. That is basically what i did, custom execution module to translate a graphql request to a single sql query (https://subzero.cloud/ https://subzero.cloud/)

scottmf 9y ago
Which n+1 problems doesn't dataloader solve?
- foota 9y ago
  You don't have to worry so much about n+1 (once you're using dataloader) as much as you do deeply nested queries, or queries that run against a large number of datatypes.
  - ruslan_talpa 9y ago
    i am not sure i follow, the deeper the query or bigger the returned dataset, the worse the performance of a dataloader type solution (see my other comment).
    - foota 9y ago
      We're agreeing here, I think. I'm saying that after taking care of the n+1 problem by using dataloader, you still have to worry about deeply nested queries.
      - andrewingram 9y ago
        This is true, but most complex UIs tends to result in queries that spread wide rather than deep. It takes some deliberate contrivance or fairly unusual real-world cases to get to more than 3-4 levels of nested relationships, and this is often the point at which you'd be thinking to deferred/lazy loading in the client anyway. I've spent a significant amount of time over the last year or so optimizing GraphQL servers built on domain-driven services (i.e. joins aren't an option) and managed to get to equal (or very marginally worse) performance to existing handcrafted endpoints that returned equivalent data (it was possible to build the same UI, even though the payloads weren't identical). There are areas where GraphQL is inherently inefficient (trying to work on ways to mitigate these issues), but the reality is that deeply-nested UI appears to be less of a problem than I originally thought it would be.

thomasfoster96 9y ago

I strongly suggest that you look at Apollo's GraphQL offerings. My 'aha' moment with GraphQL came while reading the docs for their GraphQL server[0]. IMHO Relay doesn't make a lot of sense. Apollo Client [1] has a much better feature set for most use cases, doesn't need React and is better documented. [0] http://dev.apollodata.com/tools/graphql-tools/resolvers.html http://dev.apollodata.com/tools/graphql-tools/resolvers.html [1] http://dev.apollodata.com/core/ http://dev.apollodata.com/core/

fishnchips 9y ago
+1 to that. I'm working on a (mostly) GraphQL application with a Rails backend and a React frontend with a touch of Redux. I really wanted to like Relay but the documentation was lacking (I suspect that a major API change is to blame) and the amount of boilerplate is prohibitive. On the other hand Apollo Client is straightforward, framework agnostic with great React bindings. As a web development veteran I feel that I've never been as productive as with this particular stack.
andrewingram 9y ago
Used Relay Classic for a year and a half, been using Relay Modern for a month or so. You are absolutely right, the documentation situation is terrible. The fact that the new mutation API has practically zero documentation is troubling. I've been sticking with it though, and I am enjoying it. I feel like I have a greater grasp of what's going to be executed and when than I ever did with Relay Classic, and the file size + performance improvements are worth the cost of admission in my mind.
- thomasfoster96 9y ago
  Have you been using normal Relay or one of the forks/modified versions that supports server-side rendering? The fact that Apollo Client supports server-side rendering out of the box was a big plus for me. > the file size + performance improvements are worth the cost of admission in my mind. Is this Relay Classic vs Relay Modern or Relay vs Apollo?
  - 9y ago

zackify 9y ago

I agree. All of the examples are trivial. There are a lot of nice things about graphql. Yet there are a lot of problems and annoyances other things don’t have such as query batching. Even authorizing certain graphql queries / mutations is not a trivial thing. I’ve been able to solve a couple of these things in my own app, but it’s just not something built into the spec.

djmashko2 9y ago

This is definitely a real problem and we just launched a website yesterday which we hope will grow into a resource for this kind of more advanced content: http://www.graphql.com/guides/ http://www.graphql.com/guides/ You can also see a lot of examples of GraphQL server code for JS here: https://github.com/apollographql/launchpad https://github.com/apollographql/launchpad It includes connecting to DBs, APIs, etc.

andrewingram 9y ago

Here's a high-level article about performance in general, but it shows how a UI and query could map to (for example) a function-driven API (this could be local to the server or remote): https://dev-blog.apollodata.com/optimizing-your-graphql-request-waterfalls-7c3f3360b051 https://dev-blog.apollodata.com/optimizing-your-graphql-requ... Examples more specific to a particular backend technology feel redundant because my assumption is that once you're in the land of calling functions, we don't need to hold your hands anymore. The most important thing is to be aware of the different batching strategies that are available to you in each GraphQL implementation because I believe this is the most critical part of getting a GraphQL server to perform well with anything other than a graph database.

ruslan_talpa 9y ago
assuming all your data comes form the same database, you can reduce one graphql query to one sql query that you can run on PostgreSQL (which is not a graph database). So batching is not the only option (and probably not the best)

mrskitch 9y ago

I've written a fair bit about it. We use it at AppNexus internally for our UI's, and it simply maps back to a REST API. Since each API has its quirks and oddities, it's a nice abstraction layer for consistency. http://joelgriffith.net/lessons-learned-wrapping-a-rest-api-with-graphql/ http://joelgriffith.net/lessons-learned-wrapping-a-rest-api-... For starters

fiatjaf 9y ago

As a standalone all-by-myself indie developer I was skeptical of GraphQL when it first appeared, but later I discovered it is much easier to develop APIs for my own consumption with GraphQL. The basic GraphQL boilerplate seems bad, but is actually fun to write and makes total sense. And once you have the structure in place it is super easy to add functionality. Plus bonuses if you have more than one database or are mixing data from your database and external APIs in your backend responses. Please try it for a small project, it is unbelievable, but you'll probably enjoy it. (For the record: I've just used https://github.com/graphql-go/graphql https://github.com/graphql-go/graphql and Lokka on the client, because it is simple and does nothing fancy, it's a thin wrapper over XHR, I think.)

pier25 9y ago
> Plus bonuses if you have more than one database or are mixing data from your database and external APIs in your backend responses. You can easily do that with a RESTful API too.
- fiatjaf 9y ago
  You can do anything with any programming language, framework or design pattern.
  - pier25 9y ago
    Yes, hence it's not a bonus.

pier25 9y ago

On the server side it's very similar to REST. You define your types in a schema file, and then write functions that go fetch the data for each type. These functions are called resolvers. For example you have a Product type, and then write the resolver function that queries the database and/or another API. When you have the data, you pass it back to the client via Apollo or Relay. The big advantage over REST is that the client can define what data it wants and how it wants it. If you are full stack dev this isn't such a great advantage, but for bigger projects where front/back are spread among many engineers this can be an advantage. Also, since the schema defines the types, your API is almost self documented so to speak. The big disadvantage is authentication and authorization. We kept using REST for authentication, and we couldn't find any ready made solution for role based authorization like you have in Express, Hapi, etc. I think a combination of REST and GraphQL is the better approach.

ohthehugemanate 9y ago

We're using graphql in front of a Drupal 8 data engine, with a variety of other data sources behind that. It's also for a publishing company, that has a bunch of different front end sites all served from the same content store... But with separate development groups. We're using the youshido graphql library for it... Though now that development is further along, I wish we'd chosen the webonyx one. A good GraphQL backend resolves the graph into query results efficiently, rather than just field by field. But that does take a but of getting used to....