Javascript

ADDING FEATURES TO YOUR GATSBY SITE

Oct 28, 2019

7 min read

1 Part Series

This article was taken from the above podcast.

Welcome to another edition of the Yolo Brolo podcast where we play with new technologies and you come around for the ride.

Last time we scaffolded a basic Gatsby CLI project that is pretty much empty and does nothing than display the default Gatsby contents. But we’d be continuing by adding some cool features to the site so it’s not just plain HTML, we will turn the project into a blog, add markdown pages and syntax highlighting.

EXPLORING PROJECT FILES

Here, we’d be going over the contents of the scaffolded gatsby project we got from the previous tutorial.

gatsby-config.js

This file holds some important configurations specific and also important to the entire project. Basically the information included in this file are the site meta-data which holds information about the site title, description and author. It’s important to note that these properties can be extended to include other relevant information you seem fit for the site. For our project this looks like:

module.exports = {
    siteMetadata: {
        title: "Gatsby Default Starter",
        description: `Kick off your next, great Gatsby project with this default starter.
        This barebones starter ships with the main Gatsby configuration files you
        might need.`,
        author: "@gatsbyjs",
    },
    ...
}

Also, pre-bundled to this config file are plugins that are needed for the entire project and we would be exploring these plugins and their purpose. To learn more about most of the plugins it is recommended you do a google search on them and read them up on the official gatsby documentation page:

gatsby-plugin-react-helmet: This plugin is basically concerned with Server Side Rendering using react, SEO and meta tags.
gatsby-source-filesystem: This file is used to reading files from your local file system into the Gatsby project.
gatsby-transformer-sharp: This plugin is involved with a lot of image process and according to the official documentation the plugin is used to create ImageSharp nodes from image types (images in the Gatsby project) that are supported by an image processing library known as Sharp, the plugin as provides fields in their GraphQL types for processing images in a variety of ways including resizing, cropping, and creating responsive images.
gatsby-plugin-sharp: Generally, this plugin is used by other plugins for image processing, as it provides image processing functionalities built on top of the Sharp image processing library.
gatsby-plugin-manifest: This plugin is mostly concerned with adding Progressive Web Application (PWA) features and manifest files for offline use cases to the the Gatsby project.

gatsby-browser.js

This file holds information on every API we would love to add to the project and make use of in the browser.

gastby-node.js

This is where a lot of the generation takes place but in general this file will be used for creating pages for the site.

gatsby-ssr.js

This file handles everything server side rendering on Gatsby.

src

src is the source folder and most of the important stuff happen here, one of the important files here is the index.js file

index.js: This is the main file used by Gatsby to build up your application. If you look closely, you’d discover it contains the contents served when we run localhost:8000 or the netlify generated url for our deployed project. Enter $ gatsby develop on the terminal (make sure you are in the project directory) which will enable Gatsby spin up a local server to serve your Gatsby project on "localhost:8000”. Also, from the terminal output you’d notice that we have an exposed graphql endpoint at "localhost:8000/__graphql” for having a look at the graphql queries.

BUILDING A BLOG

It’s important to note that there are lots of starters and groups of plugins to help you achieve what we are about to do and you pretty much are free to check out Gatsby blog starters. But for the purpose of this tutorial we’d be building it from scratch just to see how it’s done and get our hands dirty. Also if you are trying things out with gatsby, always checkout the documentation as it’s a totally awesome one. Doing a quick google search on gatsby markdown pages will quickly take us to the gatsby documentation on "Adding Markdown Pages” . We need the gatsby-source-filesystem plugin to add markdown support to our blog. First we have to create a posts folder within the src folder from which the plugin will read the markdown pages from. Next, we create a my-first-post.md file within the posts folder with the content:

# Hello World

Next, we need to install the gatsby-transformer-remark plugin which will convert/transform the markdown pages to HTML. To install this plugin, stop the running gatsby server by clicking CTRL + c then run the following command: $ npm install –save gatsby-transformer-remark Once the installation is complete, we add an additional section to the gatsby-config.js under the gatsby-source-filesystem plugin file like so:

module.exports = {
    …,
    {
        resolve: `gatsby-source-filesystem`,
        options: {
            name: `posts`,
            path: `${__dirname}/src/posts`
        },
    },{
        resolve: `gatsby-transformer-remark`,
    }

Next, we need to create a page template for the markdown file and add some frontmatter which includes some extra meta-data for adding extra stuff to the HTML files. The frontmatter always comes at the top of the markdown files like so:

---
path: "/blog/my-first-post”
date: "2019-06-19”
title: "My first awesome gatsby blog post”
---
# Hello World

To add the template file for the markdown pages, we need to add a templates folder to the src folder and add the page templates there(the template is basically a react component making use of a graphql query), for our case we need to create a postTemplate.js. Add the following content to the file;

import React from "react"
import { graphql } from "gatsby"
export default function Template({
  data, // this prop will be injected by the GraphQL query below.
}) {
  const { markdownRemark } = data // data.markdownRemark holds our post data
  const { frontmatter, html } = markdownRemark
  return (
    <div className="blog-post-container">
      <div className="blog-post">
        <h1>{frontmatter.title}</h1>
        <h2>{frontmatter.date}</h2>
        <div
          className="blog-post-content"
          dangerouslySetInnerHTML={{ __html: html }}
        />
      </div>
    </div>
  )
}
export const pageQuery = graphql`
  query($path: String!) {
    markdownRemark(frontmatter: { path: { eq: $path } }) {
      html
      frontmatter {
        date(formatString: "MMMM DD, YYYY")
        path
        title
      }
    }
  }`

The pageQuery variable holds the graphql query, based on the $path defined in the frontmatter and return the html (converted markdown) and frontmatter from the markdown page. The Template function receives the query result in an object parameter called data, that includes an object called markdownRemark. This object contains the frontmatter and html that wew are going to destructure from the markdownRemark variable, finally the Template function basically renders the output of the deconstructed objects. The gatsby-node.js page needs the following code to create our page:

const path = require(`path`)
exports.createPages = ({ actions, graphql }) => {
  const { createPage } = actions
  const postTemplate = path.resolve(`src/templates/postTemplate.js`)
  return graphql(`
    {
      allMarkdownRemark(
        sort: { order: DESC, fields: [frontmatter___date] }
        limit: 1000
      ) {
        edges {
          node {
            frontmatter {
              path
            }
          }
        }
      }
    }
  `).then(result => {
    if (result.errors) {
      return Promise.reject(result.errors)
    }
    return result.data.allMarkdownRemark.edges.forEach(({ node }) => {
      createPage({
        path: node.frontmatter.path,
        component: postTemplate,
        context: {}, // additional data can be passed via context
      })
    })
  })
}

After adding the code, we can check out our new feature and the markdown feature by rebuilding the project and starting our local server by running gatsby develop on the terminal, then checking out the blog page using localhost:8000/blog/my-first-post (the endpoint used to access our page has been configured in the frontmatter of the markdown). It is time to create, we can create another markdown page, we’d name my-second-post.md, We pass it the frontmatter configurations and makes it hold # Hello world again! as content, like so;

---
path: "/blog/my-second-post”
date: "2019-06-19”
title: "My second awesome gatsby blog post”
---
# Hello world again!

We move on to add some markdown code formatting syntax using the triple backticks like so;

---
path: "/blog/my-second-post”
date: "2019-06-19”
title: "My second awesome gatsby blog post”
---
# Hello world again!
    ```
    const greeting = "Hello”;
    console.log(`${greeting} world` );
    ```

Navigating to localhost:8000/blog/my-second-blog we’d see the Hello world again! Heading and the markdown formatted block of code within the triple ticks in a gray background, but that is not the prettiest syntax and we’d need to add some fancy highlighting.
To achieve the syntax highlighting we’d be using gatsby-remark-prismjs plugin for markdown. For the plugin to work we need to have gatsby-transformer-remark plugin installed (which we already have) and gatsby-remark-prismjs (which we will install shortly). To download and add the plugin to the project stop the running server using CTRL + C and run on the terminal:

$ yarn add gatsby-remark-prismjs prismjs This command will download the prismjs plugin and add all it’s dependencies to the project. In the gatsby-config.js file we add the following configurations;

{
  resolve: `gatsby-transformer-remark`,
  options: {
    plugins: [
      `gatsby-remark-prismjs`
    ]
  }
}

It is also necessary to add add the prismjs css for the syntax highlighting feature to be complete. We add the css by adding require("prismjs/themes/prism-solarizedlight.css”) to the gatsby-browser.js file. After saving the changes we have made, we spin up the server again by running gatsby develop on the terminal to see the effects of the prismjs plugin and css to our markdown pages. To make the styling a little bit more fancier and language specific, we can add javascript keyword after the three backticks in the my-second-post.md file, like so:

---
path: "/blog/my-second-post"
date: "2019-06-19”
title: "My second awesome gatsby blog post”
---
# Hello world again!
    ```javascript
    const greeting = "Hello”;
    console.log(`${greeting} world` );
    ```

Checking localhost:8000/blog/my-second-blog you’d discover the color effects are a bit different from earlier, and it looks really great now. The ease with which things are done in Gatsby is mostly because the ecosystem around Gatsby is quite big and a lot of things you’d need has mostly been done. We can further add our own custom CSS styling to the project by creating a folder styles and create a global.css file, then we include the stylesheet in gatsby-browser.js file like so;

require("./src/styles/global.css”) Then in our global.css file we add the following styles to see that it actually works:

body{
  background-color: red;
}

Reloading our browser tab at localhost:8000/blog/second-blog-post we’d discover that it actually works! Now we can go ahead to delete the codes and add the following code to make our line highlighting in our markdown pages possible;

.gatsby-highlight-code-line {
  background-color: #feb;
  display: block;
  margin-right: -1em;
  margin-left: -1em;
  padding-right: 1em;
  padding-left: 0.75em;
  border-left: 0.25em solid #f99;
}

Then in the my-second-post.md file add {2} to the javascript keyword to highlight line two of the code block, like so;

---
path: "/blog/my-second-post”
date: "2019-06-19”
title: "My second awesome gatsby blog post”
---
# Hello world again!
    ```javascript{2}
    const greeting = "Hello”;
    console.log(`${greeting} world` );
    ```
Checkout `localhost:8000/blog/my-second-post` and you’d discover that the second line of the code is highlighted! There are a lot of other styles we could also add to the markdown files.
## WRAP UP
We touched the different gatsby files of a typical gatsby project, the config files, the pre-bundled plugins and the graphql queries.
What's cool about Gatsby is that everything is statically rendered from the server, but once the page loads gatsby bootstrap up a spar and load the rest of the page dynamically and won’t request from the server everytime you reload.

Most of all the codes added to our project where lifted from the Gatsby official documentation and it’s a good practice to checkout the official Gatsby documentation when you are in doubt.

*This article was written by Opara Prosper who is a freelance writer.*

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

Building SEO-Powered Websites With Gatsby

Gatsby is a framework that leverages React for building SEO-powered websites. Many websites are created to be discovered, hence, SEO support is an important factor in such websites. Many factors influence SEO such as accessibility, correct meta-information (at the head tag) and some other external tools. Gatsby supports using appropriate meta information for individual pages to improve their presence online. In this article, we'll look at the limitations of Create React App in respect to SEO, and how Gatsby solves this with SSR. Furthermore in the article, we'll go through a tutorial on building a basic website with good SEO. Why CRA is not a good tool for SEO CRA is an opinionated tool used for building React applications but cannot be used for SEO. Here's why: When using React, you'll most probably be using a library like react-helmet (a document head manager for React) for updating meta-information about the site. The limitations of such libraries is that they contain JavaScript, which means they can only be executed on the browser (so JavaScript can run). SEO crawlers or social media tools that inspect head tags of websites (to display a card, perhaps) would not execute that JavaScript. Instead, they make use of the default meta information they can find. In CRA, the default title in public/index.html is "React App". This means, for every page you create (based on routes), they will all have the same title. They only show different titles when they are executed on the client's browser because the react-helmet library gets the chance to be executed, thereby updating the head tags. This article contains more information. How Gatsby solves React SEO problems with SSR Gatsby is a Static Site Generator (SSG) which uses Server Side Rendering (SSR) to generate static pages during the build process. What this means is that you provide dynamic meta information in every page, and during the process of static site generation, pages are server-side rendered with the specified meta information, thereby making static pages with their own details. With this technique, every page contains its own meta title, meta description and basically every meta information. The following tutorial shows how Gatsby improves SEO in web applications. Building an SEO powered site with Gatsby We'll be building a basic website with two pages: / - Home and /about - About Us. These two pages would have their own meta information attached to them during the build process. To get started, let's created our Gatsby project. Run the following in your terminal: ` This pulls the default template, and installs all necessary dependencies. In the src directory, you'll find three directories: components, images and pages. As you may observe, the template already comes with some configurations for seo and optimizing images. To build our project afresh, delete the following files/directories: ` This will leave us with components/seo.js and images. In a future series, we'll explore the gatsby-image plugin used in components/images.js. But for now, understand that it performs optimizations on images. Let's briefly explore the content of components/seo.js ` _Note that_ this component can look a bit different in another template, or you may do it differently. The SEO component receives four props: title, description, lang and meta with title as required. You can specify more props if you want or take out those you don't need. This allows different pages to specify their titles, descriptions and other meta information specific to them. Helmet is from react-helmet but is used a bit different from how it is used in CRA. It works with gatsby-plugin-react-helmet which provides server rendering support. components/seo.js also contains some GraphQL which we will cover in a future series. The Helmet plugin during the build process populates all pages with their respective meta information depending on the inputs provided during development. Now let's add our pages. With Gatsby, you do not need any routing packages for determining components to show based on specific URLs. To create a page, all you need to do is add the component's file directly under the pages directory. To create the two pages for our project, add two files: index.js for / and about.js for /about. Before proceeding with our pages, let's add a layout. Create components/layout.js and components/header.js. Add the following in components/header.js: ` Same React. The only thing new here is a different Link component from Gatsby is used. In the components/layout.js, add the following: ` For the pages, add the following to index.js: ` I added an unsplash image to images and required it require('../images/laptop.jpg') as seen above. We'll look at the usage of the SEO component soon. For pages/about.js, add the following: ` Create a new directory called styles under src and create a new file: global.css. Copy the following css styles to that file: ` For the global stylesheet to be used for the whole site, the gatsby-browser.js API file would be used. gatsby-browser.js is a reserved API file that gives access to actions within the browser. In gatsby-browser.js (at the root of your project), add the following: ` When you run the gatsby server for your project (gatsby develop), you'll get the following on localhost:8000: For /: For /about: The SEO component makes all the pages unique and SEO-ready. For index.js, we have: ` Just as we have configured the SEO component using react-helmet, this updates the meta information for the homepage during the build process. This way, the first thing crawlers will see is the unique meta details for the page, as they do not require any JavaScript to be updated. To test this, do the following: - build for project for production (gatsby run build) - serve the production build (gatsby run serve) This will run the built content on localhost:9000. You can use curl on your terminal to inspect the source code (or run inspect on the browser). ` The result: The reason it came out as "Homepage | Gatsby Default Starter" is because of the prop titleTemplate provided by Helmet which was configured like so in the SEO template: ` This appends a default title to every title provided by the pages. Conclusion In this article, we looked at how Gatsby solves the problem of SEO using server side rendering for generating static pages. The basic example used in the tutorial shows how each page contain their own meta information that can easily be crawled by SEO bots or social media tools....

Dec 16, 2020

6 mins

GatsbyReact

Performance: Optimizing Images on Gatsby Sites

Performance: Optimizing Images on Gatsby Sites Our Labs website is written using Gatsby, and uses images in many places. We have images that are both statically hosted, and images that are hosted in Contentful. The Problem We found that many of our static images weren't compressed as optimally as they could be and were inflating page sizes. This example comes from a page with many images that are being used as-is with no post-processing in the site build. Some of the images are lossless compressed PNGs that can be JPGs instead, and some of them are already JPGs but their sizes far exceed the size of the container they're in. The Solution Instead of manually optimizing each static image we can let gatsby-image do this for us. Static Images The static images can be easily fixed by replacing all uses of with from gatsby-image. GQL queries will also need to be updated to return fixed or fluid images. gatsby-image doesn't take image urls directly like a normal tag does, but instead, takes a special fluid or fixed type that optimizes the images differently. The fixed type should be used when the width and height are known, and will not change. The fluid type should be used if the image will stretch to fill the container that it's in, depending on the screen size. Here's an example of an for avatars being replaced with a fixed image. ` The type of avatarUrl needs to be changed from a string to a sharp fixed image in the GQL query. This is also where optimization parameters such as size and quality can be configured. ` Here, just width and height are specified, but there are other useful parameters such as quality and toFormat, which can be useful if you want to make sure images are converted and compressed to your liking during the build. Here's an example that ensures images have a size of 160x160 and are JPGs with 80% quality: ` All static image paths returned by the query should be relative so that gatsby-image can find them. Absolute image paths will not work with it like they do with . Optimizing Images from Contentful While the gatsby-image package makes it very easy to optimize images when you're dealing with content templates, it doesn't work well on its own if you're dealing with markdown or pre-supplied HTML. Posts on our Labs blog are written in markdown, and are stored with Contentful, and we render posts by converting them to HTML with gatsby-transformer-remark. We're able to optimize these images using gatsby-remark-images-contentful. This plugin extends gatsby-transformer-remark to output images that use parameters from Contentful's Image API, and to generate different sized versions of images that are chosen based off of the size of the device. This plugin also adds a "blur up" effect as the image is downloaded, and holds the size of the incoming image to prevent a reflow. It's also notable that using this plugin will give us image lazy loading as well, which can speed up load times for image heavy pages substantially. Here's how we configured this plugin in gatsby-config.js: ` Before & After Results Here's an example of how our teams page has improved and went from a 856kB image weight to 300kB with these simple changes. Before After Here's an example of an image heavy blog post with images from Contentful that had its initial load size cut by _almost 50%_, from 6.1MB to 3.4MB. Before After The gains seen here come mostly from lazy loading provided by gatsby-image, so images are only downloaded once they're about to come into view; however savings also come from serving images of appropriate sizes, so a mobile device such as the Pixel 2 will have an initial load of 1.6MB. We don't forcefully format all blog post images to JPG currently as there may be legitimate reasons to not use them, e.g. you want to keep transparency or embed animated gifs. Closing Gatsby makes it easy to optimize your sites without expending too much effort. If you're already using Gatsby, I'd encourage you to make sure you're using it to its fullest potential....

Aug 4, 2020

4 mins

GatsbyWeb PerformanceJavaScript

Transforming Platform Engineering Through Chargeback Programs with Shuchi Mittal

Shuchi Mittal, the Head of Cloud enablement at Honeywell, discusses how she as a leader in platform engineering has been able to transform internal platform engineering teams at other organizations by providing teams with value-added services, and how they effectively managed costs. She talks about how to treat these teams as customers, and delivering services that meet the customer needs, but also charging them for their usage. By providing policy-compliant infrastructure and unique services tailored to their requirements, platform engineering teams can showcase their commitment to supporting the success of other teams within an organization. This approach not only fosters trust but also positions platform engineering as a strategic partner rather than just a service provider. By going beyond the basic infrastructure provisioning, the platform engineering team can offer services that help development and product teams streamline their processes and improve efficiency. Shuchi shares her work at Fiserv where she implemented a chargeback system to track usage and costs effectively, incentivizing better development practices. This not only helped in managing costs but also encouraged teams to optimize their resource utilization, leading to improved overall efficiency and more easily scalable systems. Her platform engineering team recognized the importance of effectively managing financial aspects to secure upfront investment for product development. By implementing a billing system based on gigabyte hours, they aligned costs with usage, enabling teams to have a clear understanding of their resource consumption. This approach not only provided transparency but also incentivized teams to adopt cost-effective practices. By strategically managing financial aspects, the platform engineering team gained the trust of stakeholders and secured the necessary resources to drive innovation and deliver value to the organization. Shuchi’s journey of platform engineering serves as a valuable example of how a team can transition from being a basic service provider to becoming an innovation partner within an organization. By building trust, offering value-added services, and strategically managing financial aspects, the platform engineering team successfully elevated their role and became a strategic enabler of innovation. Download this episode here....

Apr 16, 2024

2 mins

Engineering LeadershipSoftware Engineering

How to Go from Software Engineer to AI Engineer with Shawn Wang

Shawn Wang discusses AI engineering’s potential impact on the software development labor market and developer experience. With the rise of artificial intelligence technologies, there is an increasing demand for professionals who can bridge the gap between AI and software engineering, and engineers are looking around for guidance on how to best learn AI. Shawn emphasizes the importance of acquiring core knowledge and skills in AI engineering, highlighting the need for a systematic approach to education and development. He envisions a future where AI engineering becomes a recognized profession, with specialized training programs and certifications. He further talks about mental models for approaching AI literacy, and skill building. Shawn also discusses the use of advanced AI technology in software development. He showcases tools like GPT Vision, which can automate tasks and generate code efficiently. While acknowledging the potential of AI in enhancing productivity, Shawn emphasizes the need to leverage AI tools to augment human capabilities rather than replace them. Download this episode here....

Apr 17, 2024

1 min

Artificial IntelligenceEngineering Leadership

ADDING FEATURES TO YOUR GATSBY SITE

1 Part Series

EXPLORING PROJECT FILES

gatsby-config.js

gatsby-browser.js

gastby-node.js

gatsby-ssr.js

src

BUILDING A BLOG

You might also like

Building SEO-Powered Websites With Gatsby

Performance: Optimizing Images on Gatsby Sites

Transforming Platform Engineering Through Chargeback Programs with Shuchi Mittal

How to Go from Software Engineer to AI Engineer with Shawn Wang

You might also like

Building SEO-Powered Websites With Gatsby

Performance: Optimizing Images on Gatsby Sites

Transforming Platform Engineering Through Chargeback Programs with Shuchi Mittal

How to Go from Software Engineer to AI Engineer with Shawn Wang