The Final Free Solo Weblog Setup With Ghost And Gatsby

Today it appears there are an infinite variety of instruments and platforms for creating your individual weblog. Nevertheless, a number of the choices on the market lean in the direction of non-technical customers and summary away all the choices for personalisation and actually making one thing your individual.

If you’re somebody who is aware of their method round front-end improvement, it may be irritating to discover a resolution that offers you the management you need, whereas eradicating the admin from managing your weblog content material.

Enter the Headless Content material Administration System (CMS). With a Headless CMS, you will get all the instruments to create and set up your content material, whereas sustaining 100% management of how it’s delivered to your readers. In different phrases, you get all the backend construction of a CMS whereas not being restricted to its inflexible front-end themes and templates.

In the case of Headless CMS techniques, I’m a giant fan of Ghost. Ghost is open-source and easy to make use of, with a number of nice APIs that make it versatile to make use of with static website builders like Gatsby.

On this article, I’ll present you ways you need to use Ghost and Gatsby collectively to get the final word private weblog setup that allows you to preserve full management of your front-end supply, however leaves all of the boring content material administration to Ghost.

Oh, and it’s 100% free to arrange and run. That’s as a result of we will probably be working our Ghost occasion regionally after which deploying to Netlify, profiting from their beneficiant free tier.

Let’s dive in!

Setting Up Ghost And Gatsby

I’ve written a starter publish on this earlier than that covers the very fundamentals, so I gained’t go too in-depth into them right here. As a substitute, I’ll concentrate on the extra superior points and gotchas that come up when working a headless weblog.

However in brief, right here’s what we have to do to get a primary set-up up and working that we will work from:

Set up an area model of the Gatsby Starter Weblog
Set up Ghost regionally
Change the supply knowledge from Markdown to Ghost (swap out gatsby-source-file system for gatsby-source-ghost)
Modify the GraphQL queries in your gatsby-node, templates, and pages to match the gatsby-source-ghost schema

For extra particulars on any of those steps, you may take a look at my earlier article.

Or you may simply begin from the code in this Github repository.

Dealing With Photos

With the fundamentals out of the best way, the primary challenge we run into with a headless weblog that builds regionally is what to do with pictures.

Ghost by default serves pictures from its personal server. So while you go headless with a static website, you’ll run right into a scenario the place your content material is constructed and served from an edge supplier like Netlify, however your pictures are nonetheless being served by your Ghost server.

This isn’t best from a efficiency perspective and it makes it unattainable to construct and deploy your website regionally (which suggests you would need to pay month-to-month charges for a Digital Ocean droplet, AWS EC2 occasion, or another server to host your Ghost occasion).

However we will get round that if we will discover one other resolution to host our pictures &mdash, and fortunately, Ghost has storage converters that allow you to retailer pictures within the cloud.

For our functions, we’re going to use an AWS S3 converter, which permits us to host our pictures on AWS S3 together with Cloudfront to provide us the same efficiency to the remainder of our content material.

There are two open-source choices obtainable: ghost-storage-adapter-s3 and ghost-s3-compat. I take advantage of ghost-storage-adapter-s3 since I discover the docs simpler to comply with and it was extra not too long ago up to date.

That being mentioned, if I adopted the docs precisely, I bought some AWS errors, so right here’s the method that I adopted that labored for me:

Create a brand new S3 Bucket in AWS and choose Disable Static Internet hosting
Subsequent, create a brand new Cloudfront Distribution and choose the S3 Bucket because the Origin

When configuring the Cloudfront Distribution, underneath S3 Bucket Entry:

Choose “Sure, use OAI (bucket can limit entry to solely Cloudfront)”
Create a New OAI

And at last, choose “Sure, replace the bucket coverage”

This creates an AWS S3 Bucket that may solely be accessed by way of the Cloudfront Distribution that you’ve got created.

Then, you simply must create an IAM Person for Ghost that may allow it to write down new pictures to your new S3 Bucket. To do that, create a brand new Programmatic IAM Person and fasten this coverage to it:

{
“Model”: “2012-10-17”,
“Assertion”: [
{
“Sid”: “VisualEditor0”,
“Effect”: “Allow”,
“Action”: “s3:ListBucket”,
“Resource”: “arn:aws:s3:::YOUR-S3-BUCKET-NAME”
},
{
“Sid”: “VisualEditor1”,
“Effect”: “Allow”,
“Action”: [
“s3:PutObject”,
“s3:GetObject”,
“s3:PutObjectVersionAcl”,
“s3:DeleteObject”,
“s3:PutObjectAcl”
],
“Useful resource”: “arn:aws:s3:::YOUR-S3-BUCKET-NAME/*”
}
] }

With that, our AWS setup is full, we simply want to inform Ghost to learn and write our pictures there as an alternative of to its native server.

To try this, we have to go to the folder the place our Ghost occasion is put in and open the file: ghost.improvement.json orghost.manufacturing.json.(relying on what setting you’re at present working)

Then we simply want so as to add the next:

{
“storage”: {
“energetic”: “s3”,
“s3”: {
“accessKeyId”: “[key]”,
“secretAccessKey”: “[secret]”,
“area”: “[region]”,
“bucket”: “[bucket]”,
“assetHost”: “https://[subdomain].instance.com”, // cloudfront
“forcePathStyle”: true,
“acl”: “non-public”
}
}

The values for accessKeyId and secretAccessKey could be discovered out of your IAM setup, whereas the area and bucket confer with the area and bucket identify of your S3 bucket. Lastly, the assetHost is the URL of your Cloudfront distribution.

Now, if you happen to restart your Ghost occasion, you will note that any new pictures you save are in your S3 bucket and Ghost is aware of to hyperlink to them there. (Be aware: Ghost gained’t make updates retroactively, so you should definitely do that very first thing after a contemporary Ghost set up so that you don’t must re-upload pictures later)

Dealing with Inside Hyperlinks

With Photos out of the best way, the following tough factor we’d like to consider is inner hyperlinks. As you might be writing content material in Ghost and inserting hyperlinks in Posts and Pages, Ghost will robotically add the location’s URL to all inner hyperlinks.

So for instance, if you happen to put a hyperlink in your weblog publish that goes to /my-post/, Ghost goes to create a hyperlink that goes to https://mysite.com/my-post/.

Usually, this isn’t a giant deal, however for Headless blogs this causes issues. It is because your Ghost occasion will probably be hosted someplace separate out of your front-end and in our case it gained’t even be reachable on-line since we will probably be constructing regionally.

Which means we might want to undergo every weblog publish and web page to appropriate any inner hyperlinks. Fortunately, this isn’t as exhausting because it sounds.

First, we are going to add this HTML parsing script in a brand new file referred to as replaceLinks.js and put it in a brand new utils folder at src/utils:

const url = require(`url`);
const cheerio = require(‘cheerio’);

const replaceLinks = async (htmlInput, siteUrlString) => {
const siteUrl = url.parse(siteUrlString);
const $ = cheerio.load(htmlInput);
const hyperlinks = $(‘a’);
hyperlinks.attr(‘href’, perform(i, href){
if (href) {
const hrefUrl = url.parse(href);
if (hrefUrl.protocol === siteUrl.protocol && hrefUrl.host === siteUrl.host) {
return hrefUrl.path
}

return href;
}

});
return $.html();
}

module.exports = replaceLinks;

Then we are going to add the next to our gatsby-node.js file:

exports.onCreateNode = async ({ actions, node, getNodesByType }) => {
if (node.inner.proprietor !== `gatsby-source-ghost`) {
return
}
if (node.inner.kind === ‘GhostPage’ || node.inner.kind === ‘GhostPost’) {
const settings = getNodesByType(`GhostSettings`);
actions.createNodeField({
identify: ‘html’,
worth: replaceLinks(node.html, settings[0].url),
node
})
}
}

You will notice that we’re including two new packages in replaceLinks.js, so let’s begin by putting in these with NPM:

npm set up –save url cheerio

In our gatsby-node.js file, we’re hooking into Gatsby’s onCreateNode, and particularly into any nodes which might be created from knowledge that comes from gatsby-source-ghost (versus metadata that comes from our config file that we don’t care about for now).

Then we’re checking the node kind, to filter out any nodes that aren’t Ghost Pages or Posts (since these are the one ones that may have hyperlinks inside their content material).

Subsequent, we’re getting the URL of the Ghost website from the Ghost settings and passing that to our removeLinks perform together with the HTML content material from the Web page/Publish.

In replaceLinks, we’re utilizing cheerio to parse the HTML. Then we will then choose all the hyperlinks on this HTML content material and map by their href attributes. We will then test if the href attribute matches the URL of the Ghost Web site — if it does, we are going to substitute the href attribute with simply the URL path, which is the inner hyperlink that we’re searching for (e.g. one thing like /my-post/).

Lastly, we’re making this new HTML content material obtainable by GraphQL utilizing Gatsby’s createNodeField (Be aware: we should do it this manner since Gatsby doesn’t can help you overwrite fields at this section within the construct).

Now our new HTML content material will probably be obtainable in our blog-post.js template and we will entry it by altering our GraphQL question to:

ghostPost(slug: { eq: $slug }) {
id
title
slug
excerpt
published_at_pretty: published_at(formatString: “DD MMMM, YYYY”)
html
meta_title
fields {
html
}
}

And with that, we simply must tweak this part within the template:

<part
dangerouslySetInnerHTML={{ __html: publish.html }}
itemProp=”articleBody”
/>

To be:

<part
dangerouslySetInnerHTML={{ __html: publish.fields.html }}
itemProp=”articleBody”
/>

This makes all of our inner hyperlinks reachable, however we nonetheless have yet one more drawback. All of those hyperlinks are <a>anchor tags whereas with Gatsby we must be utilizing Gatsby Hyperlink for inner hyperlinks (to keep away from web page refreshes and to offer a extra seamless expertise).

Fortunately, there’s a Gatsby plugin that makes this very easy to resolve. It’s referred to as gatsby-plugin-catch-links and it seems to be for any inner hyperlinks and robotically replaces the <a> anchor tags with Gatsby <Hyperlink>.

All we have to do is set up it utilizing NPM:

npm set up –save gatsby-plugin-catch-links

And add gatsby-plugin-catch-links into our plugins array in our gatsby-config file.

Including Templates And Kinds

Now the large stuff is technically working, however we’re lacking out on among the content material from our Ghost occasion.

The Gatsby Starter Weblog solely has an Index web page and a template for Weblog Posts, whereas Ghost by default has Posts, Pages, in addition to pages for Tags and Authors. So we have to create templates for every of those.

For this, we will leverage the Gatsby starter that was created by the Ghost group.

As a place to begin for this challenge, we will simply copy and paste lots of the information immediately into our challenge. Right here’s what we are going to take:

All the folder src/elements/frequent/meta — we are going to copy this into our src/elements folder (so we are going to now have a folder src/elements/meta)
The part information Pagination.js and PostCard.js — we are going to copy these into our src/elements folder
We’ll create a src/utils folder and add two information from their src/utils folder: fragments.js and siteConfig.js
And the next templates from their src/templates folder: tag.js, web page.js, writer.js, and publish.js

The meta information are including JSON structured knowledge markup to our templates. It is a nice profit that Ghost gives by default on their platform and so they’ve transposed it into Gatsby as a part of their starter template.

Then we took the Pagination and PostCard.js elements that we will drop proper into our challenge. And with these elements, we will take the template information and drop them into our challenge and they’ll work.

The fragments.js file makes our GraphQL queries loads cleaner for every of our pages and templates — we now simply have a central supply for all of our GraphQL queries. And the siteConfig.js file has a couple of Ghost configuration choices which might be best to place in a separate file.

Now we are going to simply want to put in a couple of npm packages and replace our gatsby-node file to make use of our new templates.

The packages that we might want to set up are gatsby-awesome-pagination, @tryghost/helpers, and @tryghost/helpers-gatsby.

So we are going to do:

npm set up –save gatsby-awesome-pagination @tryghost/helpers @tryghost/helpers-gatsby

Then we have to make some updates to our gatsby-node file.

First, we are going to add the next new imports to the highest of our file:

const { paginate } = require(`gatsby-awesome-pagination`);
const { postsPerPage } = require(`./src/utils/siteConfig`);

Subsequent, in our exports.createPages, we are going to replace our GraphQL question to:

{
allGhostPost(kind: { order: ASC, fields: published_at }) {
edges {
node {
slug
}
}
}
allGhostTag(kind: { order: ASC, fields: identify }) {
edges {
node {
slug
url
postCount
}
}
}
allGhostAuthor(kind: { order: ASC, fields: identify }) {
edges {
node {
slug
url
postCount
}
}
}
allGhostPage(kind: { order: ASC, fields: published_at }) {
edges {
node {
slug
url
}
}
}
}

This may pull all the GraphQL knowledge we’d like for Gatsby to construct pages primarily based on our new templates.

To try this, we are going to extract all of these queries and assign them to variables:

// Extract question outcomes
const tags = end result.knowledge.allGhostTag.edges
const authors = end result.knowledge.allGhostAuthor.edges
const pages = end result.knowledge.allGhostPage.edges
const posts = end result.knowledge.allGhostPost.edges

Then we are going to load all of our templates:

// Load templates
const tagsTemplate = path.resolve(`./src/templates/tag.js`)
const authorTemplate = path.resolve(`./src/templates/writer.js`)
const pageTemplate = path.resolve(`./src/templates/web page.js`)
const postTemplate = path.resolve(`./src/templates/publish.js`)

Be aware right here that we’re changing our previous blog-post.js template with publish.js, so we will go forward and delete blog-post.js from our templates folder.

Lastly, we are going to add this code to construct pages from our templates and GraphQL knowledge:

// Create tag pages
tags.forEach(({ node }) => {
const totalPosts = node.postCount !== null ? node.postCount : 0

// This half right here defines, that our tag pages will use
// a `/tag/:slug/` permalink.
const url = `/tag/${node.slug}`

const gadgets = Array.from({size: totalPosts})

// Create pagination
paginate({
createPage,
gadgets: gadgets,
itemsPerPage: postsPerPage,
part: tagsTemplate,
pathPrefix: ({ pageNumber }) => (pageNumber === 0) ? url : `${url}/web page`,
context: {
slug: node.slug
}
})
})

// Create writer pages
authors.forEach(({ node }) => {
const totalPosts = node.postCount !== null ? node.postCount : 0

// This half right here defines, that our writer pages will use
// a `/writer/:slug/` permalink.
const url = `/writer/${node.slug}`

const gadgets = Array.from({size: totalPosts})

// Create pagination
paginate({
createPage,
gadgets: gadgets,
itemsPerPage: postsPerPage,
part: authorTemplate,
pathPrefix: ({ pageNumber }) => (pageNumber === 0) ? url : `${url}/web page`,
context: {
slug: node.slug
}
})
})

// Create pages
pages.forEach(({ node }) => {
// This half right here defines, that our pages will use
// a `/:slug/` permalink.
node.url = `/${node.slug}/`

createPage({
path: node.url,
part: pageTemplate,
context: {
// Information handed to context is obtainable
// in web page queries as GraphQL variables.
slug: node.slug,
},
})
})

// Create publish pages
posts.forEach(({ node }) => {
// This half right here defines, that our posts will use
// a `/:slug/` permalink.
node.url = `/${node.slug}/`
createPage({
path: node.url,
part: postTemplate,
context: {
// Information handed to context is obtainable
// in web page queries as GraphQL variables.
slug: node.slug,
},
})
})

Right here, we’re looping in flip by our tags, authors, pages, and posts. For our pages and posts, we’re merely creating slugs after which creating a brand new web page utilizing that slug and telling Gatsby what template to make use of.

For the tags and writer pages, we’re additionally including pagination data utilizing gatsby-awesome-pagination that will probably be handed into the web page’s pageContext.

With that, all of our content material ought to now be efficiently constructed and displayed. However we might use a bit of labor on styling. Since we copied over our templates immediately from the Ghost Starter, we will use their types as effectively.

Not all of those will probably be relevant, however to maintain issues easy and never get too slowed down in styling, I took all the types from Ghost’s src/types/app.css ranging from the part Format till the tip. Then you’ll simply paste these into the tip of your src/types.css file.

Observe all the types beginning with kg — this refers to Koening which is the identify of the Ghost editor. These types are crucial for the Publish and Web page templates, as they’ve particular types that deal with the content material that’s created within the Ghost editor. These types be certain that all the content material you might be writing in your editor is translated over and displayed in your weblog appropriately.

Lastly, we’d like our web page.js and publish.js information to accommodate our inner hyperlink substitute from the earlier step, beginning with the queries:

Web page.js

ghostPage(slug: { eq: $slug } ) {
…GhostPageFields
fields {
html
}
}

Publish.js

ghostPost(slug: { eq: $slug } ) {
…GhostPostFields
fields {
html
}
}

After which the sections of our templates which might be utilizing the HTML content material. So in our publish.js we are going to change:

<part
className=”content-body load-external-scripts”
dangerouslySetInnerHTML={{ __html: publish.html }} />

To:

<part
className=”content-body load-external-scripts”
dangerouslySetInnerHTML={{ __html: publish.fields.html }} />

And equally, in our web page.js file, we are going to change web page.html to web page.fields.html.

Dynamic Web page Content material

One of many disadvantages of Ghost when used as a conventional CMS, is that it isn’t potential to edit particular person items of content material on a web page with out going into your precise theme information and exhausting coding it.

Say you have got a piece in your website that may be a Name-to-Motion or buyer testimonials. If you wish to change the textual content in these packing containers, you’ll have to edit the precise HTML information.

One of many nice components of going headless is that we will make dynamic content material on our website that we will simply edit utilizing Ghost. We’re going to do that through the use of Pages that we’ll mark with ‘inner’ tags or tags that begin with a # image.

So for example, let’s go into our Ghost backend, create a brand new Web page referred to as Message, kind one thing as content material, and most significantly, we are going to add the tag #message.

Now let’s return to our gatsby-node file. At present, we’re constructing pages for all of our tags and pages, but when we modify our GraphQL question in createPages, we will exclude every part inner:

allGhostTag(kind: { order: ASC, fields: identify }, **filter: {slug: {regex: “/^((?!hash-).)*$/”}}**) {
edges {
node {
slug
url
postCount
}
}
}
//…
allGhostPage(kind: { order: ASC, fields: published_at }, **filter: {tags: {elemMatch: {slug: {regex: “/^((?!hash-).)*$/”}}}}**) {
edges {
node {
slug
url
html
}
}
}

We’re including a filter on tag slugs with the regex expression /^((?!hash-).)*$/. This expression is saying to exclude any tag slugs that embody hash-.

Now, we gained’t be creating pages for our inner content material, however we will nonetheless entry it from our different GraphQL queries. So let’s add it to our index.js web page by including this to our question:

question GhostIndexQuery($restrict: Int!, $skip: Int!) {
website {
siteMetadata {
title
}
}
message: ghostPage
(tags: {elemMatch: {slug: {eq: “hash-message”}}}) {
fields {
html
}
}
allGhostPost(
kind: { order: DESC, fields: [published_at] },
restrict: $restrict,
skip: $skip
) {
edges {
node {
…GhostPostFields
}
}
}
}

Right here we’re creating a brand new question referred to as “message” that’s searching for our inner content material web page by filtering particularly on the tag #message. Then let’s use the content material from our #message web page by including this to our web page:

//…
const BlogIndex = ({ knowledge, location, pageContext }) => {
const siteTitle = knowledge.website.siteMetadata?.title || `Title`
const posts = knowledge.allGhostPost.edges
const message = knowledge.message;
//…
return (
<Format location={location} title={siteTitle}>
<Search engine optimisation title=”All posts” />
<part
dangerouslySetInnerHTML={{
__html: message.fields.html,
}}
/>
)
}

Ending Touches

Now we’ve bought a very nice weblog setup, however we will add a couple of last touches: pagination on our index web page, a sitemap, and RSS feed.

First, so as to add pagination, we might want to convert our index.js web page right into a template. All we have to do is minimize and paste our index.js file from our src/pages folder over to our src/templates folder after which add this to the part the place we load our templates in gatsby-node.js:

// Load templates
const indexTemplate = path.resolve(`./src/templates/index.js`)

Then we have to inform Gatsby to create our index web page with our index.js template and inform it to create the pagination context.

Altogether we are going to add this code proper after the place we create our publish pages:

// Create Index web page with pagination
paginate({
createPage,
gadgets: posts,
itemsPerPage: postsPerPage,
part: indexTemplate,
pathPrefix: ({ pageNumber }) => {
if (pageNumber === 0) {
return `/`
} else {
return `/web page`
}
},
})

Now let’s open up our index.js template and import our Pagination part and add it proper beneath the place we map by our posts:

import Pagination from ‘../elements/pagination’
//…
</ol>
<Pagination pageContext={pageContext} />
</Format>
//…

Then we simply want to alter the hyperlink to our weblog posts from:

<Hyperlink to={publish.node.slug} itemProp=”url”>

to:

<Hyperlink to={`/${publish.node.slug}/`} itemProp=”url”>

This prevents Gatsby Hyperlink from prefixing our hyperlinks on pagination pages — in different phrases, if we didn’t do that, a hyperlink on web page 2 would present as /web page/2/my-post/ as an alternative of simply /my-post/ like we wish.

With that completed, let’s arrange our RSS feed. It is a fairly easy step, as we will use a ready-made script from the Ghost group’s Gatsby starter. Let’s copy their file generate-feed.js into our src/utils folder.

Then let’s use it in our gatsby-config.js by changing the prevailing gatsby-plugin-feed part with:

{
resolve: `gatsby-plugin-feed`,
choices: {
question: `
{
allGhostSettings {
edges {
node {
title
description
}
}
}
}
`,
feeds: [
generateRSSFeed(config),
],
},
}

We might want to import our script together with our siteConfig.js file:

const config = require(`./src/utils/siteConfig`);
const generateRSSFeed = require(`./src/utils/generate-feed`);
//…

Lastly, we have to make one vital addition to our generate-feed.js file. Proper after the GraphQL question and the output subject, we have to add a title subject:

#…
output: `/rss.xml`,
title: “Gatsby Starter Weblog RSS Feed”,
#…

With out this title subject, gatsby-plugin-feed will throw an error on the construct.

Then for our final of entirety, let’s add our sitemap by putting in the bundle gatsby-plugin-advanced-sitemap:

npm set up –save gatsby-plugin-advanced-sitemap

And including it to our gatsby-config.js file:

{
resolve: `gatsby-plugin-advanced-sitemap`,
choices: {
question: `
{
allGhostPost {
edges {
node {
id
slug
updated_at
created_at
feature_image
}
}
}
allGhostPage {
edges {
node {
id
slug
updated_at
created_at
feature_image
}
}
}
allGhostTag {
edges {
node {
id
slug
feature_image
}
}
}
allGhostAuthor {
edges {
node {
id
slug
profile_image
}
}
}
}`,
mapping: {
allGhostPost: {
sitemap: `posts`,
},
allGhostTag: {
sitemap: `tags`,
},
allGhostAuthor: {
sitemap: `authors`,
},
allGhostPage: {
sitemap: `pages`,
},
},
exclude: [
`/dev-404-page`,
`/404`,
`/404.html`,
`/offline-plugin-app-shell-fallback`,
],
createLinkInHead: true,
addUncaughtPages: true,
}
}
}

The question, which additionally comes from the Ghost group’s Gatsby starter, creates particular person sitemaps for our pages and posts in addition to our writer and tag pages.

Now, we simply must make one small change to this question to exclude our inner content material. Identical as we did within the prior step, we have to replace these queries to filter out tag slugs that include ‘hash-’:

allGhostPage(filter: {tags: {elemMatch: {slug: {regex: “/^((?!hash-).)*$/”}}}}) {
edges {
node {
id
slug
updated_at
created_at
feature_image
}
}
}
allGhostTag(filter: {slug: {regex: “/^((?!hash-).)*$/”}}) {
edges {
node {
id
slug
feature_image
}
}
}

Wrapping Up

With that, you now have a completely functioning Ghost weblog working on Gatsby you could customise from right here. You’ll be able to create all your content material by working Ghost in your localhost after which if you find yourself able to deploy, you merely run:

gatsby construct

After which you may deploy to Netlify utilizing their command-line device:

netlify deploy -p

Since your content material solely lives in your native machine, it’s also a good suggestion to make occasional backups, which you are able to do utilizing Ghost’s export characteristic.

This exports all your content material to a json file. Be aware, it doesn’t embody your pictures, however these will probably be saved on the cloud anyway so that you don’t want to fret as a lot about backing these up.

I hope you loved this tutorial the place we lined:

Organising Ghost and Gatsby;
Dealing with Ghost Photos utilizing a storage converter;
Changing Ghost inner hyperlinks to Gatsby Hyperlink;
Including templates and types for all Ghost content material varieties;
Utilizing dynamic content material created in Ghost;
Organising RSS feeds, sitemaps, and pagination.

If you’re inquisitive about exploring additional what’s potential with a headless CMS, take a look at my work at Epilocal, the place I’m utilizing the same tech stack to construct instruments for native information and different unbiased, on-line publishers.

Be aware: You could find the full code for this challenge on Github right here, and you can too see a working demo right here.

Additional Studying on Smashing Journal

“Constructing Gatsby Themes For WordPress-Powered Web sites,” Paulina Hetman
“Constructing An API With Gatsby Features,” Paul Scanlon
“Superior GraphQL Utilization In Gatsby Web sites,” Aleem Isiaka
“Gatsby Serverless Features And The Worldwide Area Station,” Paul Scanlon