updated Gatsby links to be relative

docs/blog/2018-05-11-six-reasons-i-chose-gatsby/index.md

@@ -8,21 +8,21 @@ canonicalLink: https://www.raygesualdo.com/posts/six-reasons-i-chose-gatsby/
 publishedAt: raygesualdo.com
 ---
 
-Spoiler alert: I'm a big fan of [Gatsby](https://gatsbyjs.org/). I've worked with it multiple times and I'm continually impressed with its power and flexibility. For those who aren't familiar, Gatsby is an open-source static site generator incorporating React and GraphQL. A few weeks ago, I switched my site to Gatsby and wanted to share my reasons for doing so. Plenty of articles have been written about _how_ to build a Gatsby site, but I wanted to talk about _why_ Gatsby is a great choice. I've outlined these reasons below in no particular order (the numbering is only for organizational purposes). I hope they give you a better understanding of Gatsby's benefits and features.
+Spoiler alert: I'm a big fan of [Gatsby](/). I've worked with it multiple times and I'm continually impressed with its power and flexibility. For those who aren't familiar, Gatsby is an open-source static site generator incorporating React and GraphQL. A few weeks ago, I switched my site to Gatsby and wanted to share my reasons for doing so. Plenty of articles have been written about _how_ to build a Gatsby site, but I wanted to talk about _why_ Gatsby is a great choice. I've outlined these reasons below in no particular order (the numbering is only for organizational purposes). I hope they give you a better understanding of Gatsby's benefits and features.
 
 ## #1: It's React
 
 I've been working with React for the better part of 3.5 years. I know it. I'm efficient in it. Being able to create my site markup with React makes complete sense for me. More than that however, by using React as its templating engine, Gatsby also benefits from all the wonderful React components developed by the community. Like CSS-in-JS? Use it ([styled-components](https://styled-components.com) FTW!). Have a favorite React UI kit? Throw it in there. Any React component that can be server-side rendered, which is most of them, can be used with Gatsby. This opens up a whole new set of possibilities when building out your "static" site.
 
 ## #2: An extensive, well-architected plugin system
 
-One of the first things about Gatsby that impressed me was its plugin system. Like many other OSS tools such as Webpack and Babel, much of the power of Gatsby is provided by plugins. And that's a good thing. Its plugin architecture allows for incredibly deep integrations into almost every aspect of Gatsby: build configuration, data extraction and transformation, the build process, the browser at runtime, etc. This system has allowed not only the core Gatsby team to create powerful plugins, but the community to create equally powerful plugins as well. I've even tried my hand at [writing one](https://github.com/raygesualdo/gatsby-plugin-settings) (quite successfully, I might add). If there's a task you're looking to accomplish with Gatsby, odds are there is already a plugin for it. And if not, there's [plenty of documentation](https://www.gatsbyjs.org/docs/plugin-authoring/) to help you get started writing one.
+One of the first things about Gatsby that impressed me was its plugin system. Like many other OSS tools such as Webpack and Babel, much of the power of Gatsby is provided by plugins. And that's a good thing. Its plugin architecture allows for incredibly deep integrations into almost every aspect of Gatsby: build configuration, data extraction and transformation, the build process, the browser at runtime, etc. This system has allowed not only the core Gatsby team to create powerful plugins, but the community to create equally powerful plugins as well. I've even tried my hand at [writing one](https://github.com/raygesualdo/gatsby-plugin-settings) (quite successfully, I might add). If there's a task you're looking to accomplish with Gatsby, odds are there is already a plugin for it. And if not, there's [plenty of documentation](/docs/plugin-authoring/) to help you get started writing one.
 
 ## #3: The data fetching layer
 
 With any website, one needs to have data/content injected into markup to generate HTML. With static site generators, this usually involves writing Markdown files adjacent to template files that get merged together in some way at build time. Gatsby takes a different approach by providing a data fetching abstraction layer between your data/content and your templates. This brings about a huge paradigm shift both in how data is accessed in the templates as well as from where data can be pulled (we'll look at the latter in reason #4).
 
-With Gatsby, the entirety of your site's data is accessed via a local [GraphQL](https://graphql.org/) API. If you've never worked with GraphQL before, that's okay; Gatsby's docs [walk you through the process](https://www.gatsbyjs.org/docs/querying-with-graphql/). In your page templates, you can specify the data you require for that page as a GraphQL query. Then, when Gatsby's build process runs, it analyzes the query and provides the requested data to the template. Future versions of Gatsby will also let you do this at the component level as well. This allows you to build up your templates using the React's normal component paradigm.
+With Gatsby, the entirety of your site's data is accessed via a local [GraphQL](https://graphql.org/) API. If you've never worked with GraphQL before, that's okay; Gatsby's docs [walk you through the process](/docs/querying-with-graphql/). In your page templates, you can specify the data you require for that page as a GraphQL query. Then, when Gatsby's build process runs, it analyzes the query and provides the requested data to the template. Future versions of Gatsby will also let you do this at the component level as well. This allows you to build up your templates using the React's normal component paradigm.
 
 ## #4: Multiple data sources