Javascript

ADDING FEATURES TO YOUR GATSBY SITE

Published Oct 28, 2019

Updated Feb 14, 2023

7 min read

1 Part Series

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

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.

Getting Started with GatsbyJS

GatsbyJS is a React framework and a Static Site Generator (SSG) tool used in building web applications. It combines Server Side Rendering (SSR) features, and static site development for building SEO-powered, secured, and fast applications. In this article we’ll start with an introduction to Gatsby, we’ll learn the terms SSG, CSR, and SSR, how Gatsby improves SEO, and then we’ll build a simple website with Gatsby. Introduction GatsbyJS is built on React. React is a frontend UI library for frontend implementations. It supports the idea of small components that merges with other components to make bigger components. As a UI library, React is a tool that can be combined with other tools for building web applications. Therefore, React on its own may require other tools (like routing tools, webpack server, and so on) for building full-fledged frontend applications. With that being said, when you install React, you need to install other tools to make up your application. This results in an opinionated setup aided by Create React App (CRA). Despite this, more configurations and tools needed to be installed for a full application. Then, Gatsby! Gatsby is an opinionated framework that takes away the hassle of setting up the application and allows you to begin development immediately. Asides from this, Gatsby also solves the issue of Search Engine Optimisation (SEO) that using only React provides. react-helmet is not an effective SEO solution. This article explains that further. SSR, CSR, and SSG Client-Side Rendering (CSR) In CSR, all routings and renderings are handled by the browser with JavaScript. For this technique, different HTML files are not created for different pages, instead, one page referencing some JavaScript files that determine what to display depending on the URL. React is a CSR tool. This means all routings are handled by the browser. In React, you have an index.html file found in the public folder which codes similar to this: ` After the build process (npm run build), the index.html will look like this: ` The referenced .js files handles all routings and responds to the URL with contents to share. build/index.html is only fetched once, also with the JavaScript files. This may result in low page load speed due to fetching all resources. This method affects SEO in such a way that SEO crawlers only see React App and does not see every other meta changes because those changes only happen when libraries like react-helmet are executed (which is only on the browser). Server Side Rendering In contrast to CSR, SSR involves populating the browser with resources from the server. This means that for every route change, a request is made to the server to fetch new resources. SSR is perfect for SEO because SEO crawlers get the right meta information when any page is requested. SSR also has its cons, one of which is a delay when navigating between pages. CSR wins in this area because all JavaScript resources are fetched on the first request and every other navigation does not need a page refresh. Static Site Generator An SSG is a tool or set of tools that create static HTML pages from input files or content sources. Many SSG tools work in various ways but most of them take away the issues of security and slow fetching that database-driven platforms use. SSG takes content from different sources and builds them all into static pages which can be accessed faster when fetched by a browser. How Gatsby improves SEO Gatsby is an SSG tool that solves the issue of SEO that CSR brings and also makes routing faster compared to SSR. Gatsby does this by pre-building the web application before it is hosted. During the build process, all meta information provided within components is attached to the built pages. So when SEO crawlers or social sharing tools access any page of the application, they get access to the meta-information that has been provided to all pages during development. This does not involve any rendering in the browser. The built files are static pages which looks like each page was built separately like so: ` Building a simple website with Gatsby To show how Gatsby sites are built, we’ll be building a very simple website. No much complexities or dynamics, just simple. Install the CLI tool Firstly, install the gatsby CLI tool. Or you can use npx if that’s what you want. ` Create new site You can either create a new Gatsby site with a basic template ([gatsby-starter-default]9https://www.gatsbyjs.com/starters/gatsbyjs/gatsby-starter-default/)) provided by the team, or use a specify another template to customize. For the default template, a new site is created like so: ` Where new-site is the name of the project you’re creating. This gives the following project structure: The template provides SEO configurations using GraphQL which you can improve. To see the site in action, run: ` At localhost:8000, you’ll find your site displayed like so: Alternatively, you can specify a template you want to use. You can find different starter templates from their list of starter libraries. To use a template, say, gatsby-starter-blog, the following command will be used: ` This gives the following project structure: On starting the development server, localhost:8000 shows this: Improving the gatsby-starter-default template The template has three folders under src namely components, images and pages. The components and images page are optional, but pages is a required page for Gatsby. Unlike React, where you need a router library to show a set of components for a particular URL, in Gatsby, you create pages by having React JavaScript files under the pages folder. Let’s add an about page under pages like so: In about.js, you can create your React components or import components. For example: ` SEO is a component that dynamically updates meta information about each pages and Layout is a wrapper component that serves as the layout of all pages. This can be configured to fit your needs too. When you start your development server, go to localhost:8000/about and you’ll find this: Note that: whatever you can do in React (components structuring, prop-types, and so on), you can do the same in Gatsby. Gatsby makes things easier allow you to focus on the important parts of your application and pre-building your site to make SEO-fit. Also, Gatsby makes your site fast and since they are static pages, they can be served from anywhere (like CDNs). Conclusion Gatsby goes beyond the general understanding of “static pages”. Gatsby can source content from Content Management Systems and build static pages for them. An example is gatsby-source-instagram. It sources content from Gatsby at every building process, source the latest content from Instagram, and makes them available on your website. There a lot of other awesome applications that can be achieved by using Gatsby, such as e-commerce tools, portfolios, and so on. Here's a gallery of sites using Gatsby. Another beautiful thing about Gatsby is the community. You’ll find a ton of plugins that make development easier and more effective. This article gives introductory information on what makes Gatsby an awesome tool. There are still more to learn to make the best use of Gatsby such as Gatsby and GraphQL, SSR APIs, and many more. Their documentation gives a very great guide to learning more about the tool. I hope this article gives you reasons to try out Gatsby in your next project....

Dec 14, 2020

7 mins

JavaScriptReactGatsby

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

Building a Stripe App: A Step-by-Step Guide to QR Code Generation

Building a Stripe App: A Step-by-Step Guide to QR Code Generation Why Build a Stripe App? I recently participated in an audio space with the Stripe team, and something they said really stuck with me: the Stripe app store is a growing area that isn't overly saturated yet. There's a lot of potential for new apps, and companies can use this opportunity to grow. I work at a company called This Dot Labs, and we've created several Stripe apps and even own one. After looking at the data, I can confirm that the Stripe team was right! Creating a QR Code Generator App For this tutorial, we'll build a QR code app that can take a URL and generate a code for it. This is a good use case to help you understand the ins and outs of Stripe's developer tools. Why QR Codes? QR codes are useful tools that have become common in e-commerce, restaurants, and other industries. While Stripe already has a QR code tool, we'll make our own to familiarize ourselves with their syntax and problem-solving approaches. Project Structure Before we dive into the implementation, let's look at the structure of our Stripe App QR Code project: * .vscode: Contains settings for Visual Studio Code * source/views: Holds the main application views * .gitignore: Specifies files to ignore in version control * stripe-app.json: Defines the Stripe app configuration * ui-extensions.d.ts: TypeScript declaration file for UI extensions * .build: this is where the built Stripe app gets placed. Step-by-Step Implementation 1\. Install Stripe Locally First, you need to install Stripe on your local machine. The documentation provides great instructions for this: * For Mac users: Use Brew to install * For Windows users: Download the package and add it to your environment variables You can find the details here in the stripe docs to install the Stripe CLI https://docs.stripe.com/stripe-cli When using Windows, you must do stripe login from Powershell, NOT from Git bash or any other tool. After the server is up, then you can continue using git bash for everything else. After stripe login, you need to enter stripe apps start. Once you do that, the server is up and running and you can go back to using git bash or any other tool. 2\. Install Dependencies We'll be using an extra package for QR code generation. Install it using npm: ` 3\. Set Up the Main Component Let's look at the home.tsx file, where we'll use Stripe's UI components: ` These components are similar to other UI libraries like Bootstrap or Tailwind CSS. 4\. Create the UI Structure Our app will have: * An input field for the URL * Validation using a regex pattern * Error handling for invalid URLs * QR code generation and display Here is the Home.tsx file that is located in the src/views folder ` * ContextView` is at the top level of the app where we see the Title and the link to the Stripe Docs that we placed in our Context View. * Box is how you use Divs. * Banners can be used to show notification errors or any other item you wish to display. * Textfields are input fields. * Everything else is pretty self-explanatory. 5\. Handle Content Security Policy One problem I personally ran into was when I tried to redirect users, the Stripe policies would block it since I did not express that I knew what it was doing. I had to go into the stripe-app.json file and mention the specific security policies. For this particular exercise, I kept these as null. This is my stripe-app.json file. ` 6\. Configure App Views As you can see here, the stripe-app.json file shows the views for each file I have. The Home.tsx file and the Invoice.tsx are also included This is our way of saying that for each view we have, show the app functionality on that page. Our stripe-app.json file will show it but also, the manifest.js file in our .build folder will also show the same. Any view that doesn't have a file will not show the application's functionality. So, if I were to go to transactions, the app would not show the same logic as the home or invoices page. By following these steps, you'll have a fully functional QR code generator app for Stripe. This is just a simple example, but the potential for Stripe apps is massive, especially for businesses serving e-commerce customers. If you need help or get stuck, don't hesitate to reach out, danny.thompson@thisdot.co. The Stripe team is also very active in answering questions, so leverage them as a resource. Happy coding!...

Dec 18, 2024

4 mins

stripe

D1 SQLite: Writing queries with the D1 Client API

Writing queries with the D1 Client API In the previous post we defined our database schema, got up and running with migrations, and loaded some seed data into our database. In this post we will be working with our new database and seed data. If you want to participate, make sure to follow the steps in the first post. We’ve been taking a minimal approach so far by using only wrangler and sql scripts for our workflow. The D1 Client API has a small surface area. Thanks to the power of SQL, we will have everything we need to construct all types of queries. Before we start writing our queries, let's touch on some important concepts. Prepared statements and parameter binding This is the first section of the docs and it highlights two different ways to write our SQL statements using the client API: prepared and static statements. Best practice is to use prepared statements because they are more performant and prevent SQL injection attacks. So we will write our queries using prepared statements. We need to use parameter binding to build our queries with prepared statements. This is pretty straightforward and there are two variations. By default we add ? ’s to our statement to represent a value to be filled in. The bind method will bind the parameters to each question mark by their index. The first ? is tied to the first parameter in bind, 2nd, etc. I would stick with this most of the time to avoid any confusion. ` I like this second method less as it feels like something I can imagine messing up very innocently. You can add a number directly after a question mark to indicate which number parameter it should be bound to. In this exampl, we reverse the previous binding. ` Reusing prepared statements If we take the first example above and not bind any values we have a statement that can be reused: ` Querying For the purposes of this post we will just build example queries by writing them out directly in our Worker fetch handler. If you are building an app I would recommend building functions or some other abstraction around your queries. select queries Let's write our first query against our data set to get our feet wet. Here’s the initial worker code and a query for all authors: ` We pass our SQL statement into prepare and use the all method to get all the rows. Notice that we are able to pass our types to a generic parameter in all. This allows us to get a fully typed response from our query. We can run our worker with npm run dev and access it at http://localhost:8787 by default. We’ll keep this simple workflow of writing queries and passing them as a json response for inspection in the browser. Opening the page we get our author results. joins Not using an ORM means we have full control over our own destiny. Like anything else though, this has tradeoffs. Let’s look at a query to fetch the list of posts that includes author and tags information. ` Let’s walk through each part of the query and highlight some pros and cons. ` * The query selects all columns from the posts table. * It also selects the name column from the authors table and renames it to author_name. * It aggregates the name column from the tags table into a JSON array. If there are no tags, it returns an empty JSON array. This aggregated result is renamed to tags. ` * The query starts by selecting data from the posts table. * It then joins the authors table to include author information for each post, matching posts to authors using the author_id column in posts and the id column in authors. * Next, it left joins the posts_tags table to include tag associations for each post, ensuring that all posts are included even if they have no tags. * Next, it left joins the tags table to include tag names, matching tags to posts using the tag_id column in posts_tags and the id column in tags. * Finally, group the results by the post id so that all rows with the same post id are combined in a single row SQL provides a lot of power to query our data in interesting ways. JOIN ’s will typically be more performant than performing additional queries.You could just as easily write a simpler version of this query that uses subqueries to fetch post tags and join all the data by hand with JavaScript. This is the nice thing about writing SQL, you’re free to fetch and handle your data how you please. Our results should look similar to this: ` This brings us to our next topic. Marshaling / coercing result data A couple of things we notice about the format of the result data our query provides: Rows are flat. We join the author directly onto the post and prefix its column names with author. ` Using an ORM we might get the data back as a child object: ` Another thing is that our tags data is a JSON string and not a JavaScript array. This means that we will need to parse it ourselves. ` This isn’t the end of the world but it is some more work on our end to coerce the result data into the format that we actually want. This problem is handled in most ORM’s and is their main selling point in my opinion. insert / update / delete Next, let’s write a function that will add a new post to our database. ` There’s a few queries involved in our create post function: * first we create the new post * next we run through the tags and either create or return an existing tag * finally, we add entries to our post_tags join table to associate our new post with the tags assigned We can test our new function by providing post content in query params on our index page and formatting them for our function. ` I gave it a run like this: http://localhost:8787authorId=1&tags=Food%2CReview&title=A+review+of+my+favorite+Italian+restaurant&content=I+got+the+sausage+orchette+and+it+was+amazing.+I+wish+that+instead+of+baby+broccoli+they+used+rapini.+Otherwise+it+was+a+perfect+dish+and+the+vibes+were+great And got a new post with the id 11. UPDATE and DELETE operations are pretty similar to what we’ve seen so far. Most complexity in your queries will be similar to what we’ve seen in the posts query where we want to JOIN or GROUP BY data in various ways. To update the post we can write a query that looks like this: ` COALESCE acts similarly to if we had written a ?? b in JavaScript. If the binded value that we provide is null it will fall back to the default. We can delete our new post with a simple DELETE query: ` Transactions / Batching One thing to note with D1 is that I don’t think the traditional style of SQLite transactions are supported. You can use the db.batch API to achieve similar functionality though. According to the docs: Batched statements are SQL transactions ↗. If a statement in the sequence fails, then an error is returned for that specific statement, and it aborts or rolls back the entire sequence. ` Summary In this post, we've taken a hands-on approach to exploring the D1 Client API, starting with defining our database schema and loading seed data. We then dove into writing queries, covering the basics of prepared statements and parameter binding, before moving on to more complex topics like joins and transactions. We saw how to construct and execute queries to fetch data from our database, including how to handle relationships between tables and marshal result data into a usable format. We also touched on inserting, updating, and deleting data, and how to use transactions to ensure data consistency. By working through these examples, we've gained a solid understanding of how to use the D1 Client API to interact with our database and build robust, data-driven applications....

Dec 23, 2024

6 mins

JavaScript

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

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

Getting Started with GatsbyJS

Performance: Optimizing Images on Gatsby Sites

Building a Stripe App: A Step-by-Step Guide to QR Code Generation

D1 SQLite: Writing queries with the D1 Client API

Let's innovate together!

You might also like

Getting Started with GatsbyJS

Performance: Optimizing Images on Gatsby Sites

Building a Stripe App: A Step-by-Step Guide to QR Code Generation

D1 SQLite: Writing queries with the D1 Client API