Encapsulating data on GraphQL using Loaders
This story was moved to: https://jonathancardoso.com/en/blog/encapsulating-data-on-graphql-using-loaders/
If you have already used GraphQL, you probably saw that it can consume data coming from the most varied sources, be it a local database or a external API, while centralizing them in a single, self-contained, API.
Here at Entria, we built a structure using files that we call Loaders, which are kinda like a database abstraction layer, but for our GraphQL data sources. Here is a introduction to this simple concept, heavily used everywhere else.
You can use them to wrap your data fetching logic, this way it doesn’t matter where this data is coming from, be it, for example, your MongoDB instance:
or an external API:
Your GraphQL resolvers are not going to know about how this data is fetched, all they expect is a single, well-defined interface, that you have already set:
This allows you to create powerful models for those data sources, permitting you to not have just the data fetching logic isolated, but even more complex logic, like access control rules, which I’ve written about on another post:
The examples above uses just simple functions, but imagine a single Loader file per object type that your GraphQL server exposes, with multiple simple functions for retrieving data related to this object.
Besides the data fetching encapsulation, we also use those loaders to hook up the dataloader library from Facebook, which basically acts as a per request cache, to make sure one single record is not retrieved more than one time, from their Readme:
DataLoader is first and foremost a data loading mechanism, and its cache only serves the purpose of not repeatedly loading the same data in the context of a single request to your Application. To do this, it maintains a simple in-memory memoization cache (more accurately:
.load()is a memoized function).
Check our GraphQL dataloader boilerplate for a more complete example:
