11

After see this documentation I'm not sure if to use a simple context, as I has done other times, or if it is better to use dataSources to handle the database.

DataSource is the correct way to comunicate with the database or it is better use it only to comunicate with a REST API?

Basically, does it have any advantage to use dataSources vs context in this case?

alexojegu
  • 754
  • 7
  • 21

3 Answers3

1

I think it's better to go with DataSource (as the name suggests) and it might be easy to add a caching layer on top of it. You can create a DBDataSource class extending the DataSource class since Apollo doesn't provide any DBDataSource class.

DataSource class is a generic Apollo data source class whereas RESTDataSource class that is responsible for fetching data from a REST API.

So to fetch data from rest APIs it's better to go with RESTDataSource.

Build a custom data source

Apollo doesn't have support for a SQL data source yet (although we'd love to help guide you if you're interested in contributing), so we will need to create a custom data source for our database by extending the generic Apollo data source class. You can create your own with the apollo-datasource package.

Here are some of the core concepts for creating your own data source:

  1. The initialize method: You'll need to implement this method if you want to pass in any configuration options to your class. Here, we're using this method to access our graph API's context.
  2. this.context: A graph API's context is an object that's shared among every resolver in a GraphQL request. We're going to explain this in more detail in the next section. Right now, all you need to know is that the context is useful for storing user information.
  3. Caching: While the REST data source comes with its own built-in cache, the generic data source does not. You can use our cache primitives to build your own, however!
Abhishek
  • 1,302
  • 10
  • 18
1

I generally keep resolvers very thin, pass the incoming args to dataSources and they make models and loaders communicate. Most of the logic and validations are in models. You may of course make your own rules like "don't call another dataSource inside a dataSource. Pass their outpus to make them communicate through resolvers" etc. This is only an example of course. Not a strict rule I follow. There may be better solutions and actually for simple things, using models directly is much more straightforward. But dataSources help you keep things organised and if you want to add caching etc, you can create a BaseDataSource, put all the logic in that and just extend it with other dataSources.

Onur Önder
  • 1,002
  • 1
  • 10
  • 16
0

If you look at the documentation that your pointed out. You add data Sources when initializing Apollo Server like this :

const server = new ApolloServer({
  typeDefs,
  dataSources: () => ({
    launchAPI: new LaunchAPI(),
    userAPI: new UserAPI({ store })
  })
});

and it is because of this dataSources becomes the part of context. If you remember you do the de-structuring of context to expose dataSources as shown here

module.exports = {
  Query: {
    launches: (_, __, { dataSources }) =>
      dataSources.launchAPI.getAllLaunches(),
    launch: (_, { id }, { dataSources }) =>
      dataSources.launchAPI.getLaunchById({ launchId: id }),
    me: (_, __, { dataSources }) => dataSources.userAPI.findOrCreateUser()
  }
};

If you want to access the instance of a dataSource such as UserAPI or LaunchAPI, you will have to do that with dataSources.userAPI

logeekal
  • 525
  • 4
  • 13