TL;DR; Gatsby uses graphql as a common interface to query data without assuming anything from your data source, by doing this it allows you to add, remove or change your data source without further implications for your code.
The power of ORMs
As a Ruby on Rails developer who also loves JavaScript, I have seen and used multiple Node.js frameworks without ever falling in love with any of them, and one of the main reasons for it is the ActiveRecord.
The ActiveRecord (commonly referred to as AR in the Rails community) is the ORM that comes prepacked with Ruby on Rails, it allows you to communicate with your database using an object-oriented interface that normally ends up being way more readable and expressive than plain SQL queries. And although one of the main features of the AR is its powerful and expressive API, it is probably the fact that it adds an additional layer between your data and your code what ends up being the most interesting feature from this ORM.
Adding that extra layer of communication allows developers to switch between database engines or even database paradigms (SQL or no SQL). And although switching a database engine is not a common thing to do for an application, you normally get to work with different data sources in different projects.
The ActiveRecord allows you to switch between database engines through different projects, to choose what fits best for your application, without having to relearn or adapt any of your previous implementations, which eventually, allows you to be way more productive in every new project you start.
Beyond ORMs
ORMs, like the ActiveRecord, end up being powerful implementations that come with enormous benefits (and some tradeoffs) when working with a database as a source of information, but in modern web development, data often comes from a more diverse pool of options, from traditional database to web services, the filesystem, cloud databases and so much more. It is common for modern web projects to bring data from a combination of diverse sources that an ORM is not made to understand.
Enter graphql. graphql is described according to their website(https://graphql.org/) as a query for your API, and although one may come first to mind is a web service, an API can actually be whatever source that exposes a way to communicate with your data, and this is where things get increasingly interesting for modern web development.
Given that graphql does not assume anything from your data source, just that it should have an interface of communication, you can actually use graphql to query data from any given source, precisely as Gatsby does, more from this later.
This gives you that extra layer of abstraction, that allows you to plug your application into different data sources, with probably a different API for each one of them, and communicate with them using a common API, the graphql query language.
This benefit gets more important in the current landscape for web development where data can come from a numerous and diverse pool of sources. Having a common API to communicate with any data sources allows you to add, remove, or change data sources for any project, depending on the needs of each individual project, without having to adapt your code or relearn anything.
Gatsby and graphql
Gatsby uses graphql for multiple reasons that are extensively explained in the docs(https://www.gatsbyjs.org/docs/why-gatsby-uses-graphql/), one of them is as a form of communication with whatever data source you are using.
Remember that Gatsby does not have an opinion on the kind of data source you may use for any web application you are building with Gatsby, so it is important for the framework to have a common interface of communication that does not change for any data source. This is where Gatsby and graphql make the perfect match.
With this combination, you may use the Wordpress graphql server, or the Wordpress REST API as a data source for one project, and the filesystem with a cloud database for another one, without having to relearn the framework or adapt your React components who may be reused across multiple projects.
The source plugins
What allows graphql to adapt to any data source, is that it is a super abstract API, with no implementations for any data source. This means that for any data source, you have to implement the communication between your graphql engine and the data source’s API.
Gatsby solves this for you through the implementation of plugins and the vibrant community around the framework that has implemented numerous plugins for hundreds of data sources. This means that any developer may only implement the integration between graphql and any data source once, then, if it is packaged as a plugin, this implementation may be reused between different projects and developers.
This makes Gatsby one of the first web frameworks that allow the usage of multiple data sources and APIs without forcing you to relearn anything, adapt your current implementations, or modify your code when changing data sources for an existing project.
This feels like the power of the ActiveRecord for Rails but way more powerful and it is the reason why after years of exploring Node.js frameworks, Gatsby felt like the right way of using JavaScript for modern web applications.
Top comments (1)
Nice article Uriel, I'm expecting for more Gatsby and React content in CodigoFacilito