Demystifying The New Gatsby Framework

 Gatsby 4 came out in October 2021 with a lot of new features. It may seem as if Gatsby 4 didn’t cause a big stir among developers, but it brought several game-changing features. Let’s see what v4 brings to the table.

After the release of Gatsby 4, the Gatsby team saw the biggest rise in signups on Gatsby Cloud. According to Gatsby co-founder Kyle Mathews:

“Gatsby 4 is the most powerful version of Gatsby yet. We’ve made Gatsby 10x faster to build and deploy by opening up two new rendering modes, adding support for Parallel Query Processing, and making a host of other optimizations and improvements.”

— Kyle Mathews

Until a few months ago, Gatsby.js was best suited to make not-so-big Jamstack websites, but with the release of Gatsby 4, how well does Gatsby work with big and rapidly-changing pages? And how will it compare to other frameworks like Next.js? We will hopefully answer these questions in the next article!

New Gatsby 4 Features #

Gatsby 3 had a lot of useful features, and it stood out among other pre-rendering frameworks due to being extremely fast when using Static Site Generation. However, it lacked the tools of other frameworks — mainly Next.js — to render pages on request using Server-Side Rendering. Gatsby heard its community, and besides a lot of optimization features, Gatsby 4 brought two more rendering options: Deferred Static Generation (DSG) and the good old Server-Side Rendering (SSR).

Deferred Static Generation (DSG) #

One of the problems that a lot of people had with Gatsby was its very long build times. When using SSG, building the pages and all the heavy lifting had to be done on the server, which led to longer build times as pages in your site grew. To solve this, Gatsby started to use incremental building only to build new or changed pages and keep the other ones in the cache. However, the first build without cache always took a long time to finish. The incremental building is very helpful, but it didn’t tackle the roots of the problem, and that’s where Deferred Static Generation comes in.

Deferred Static Generations is very similar to what SSG achieves, but it is more efficient and has a different method of delivering pages. In DSG, you can choose pages to “delay,” which means not to build with the rest of the pages but once a user requests them. After the first request, the page will be available in the CDN and will be the same as any other page generated with SSG. This is very useful when a site has old and unvisited pages that aren’t worth building on each production build.

If you are worried that DSG can tank your page’s SEO, remember that pages built using DSG only behave as a Server-Side Rendered the first time they are requested, and then they act just like any other SSG page. So, according to Gatsby, your page will act as an SSG 99.9% of the time, and Google will analyze its SEO that way.

As you may notice, DSG requires a running server to listen for user requests and build the requested page for every other user onwards. It is a game-changing feature in Gatsby since Gatsby was known for being a server-less SSG framework, but now you can combine SSG with other rendering options involving a server. Even though it changes the backend structure — only if you use DSG or SSR — it gives developers more flexibility to work with Gatsby.

Server-Side Rendering (SSR) #

If DSG uses a server to work, does that mean that Gatsby can use a server to render all pages on request time? Absolutely yes. This was the most long-awaited feature in Gatsby and the only one that made a lot of developers choose other pre-rendering frameworks over Gatsby. In case you don’t know, Server-Side Rendering consists in building a page each time a user requests it. And it’s very useful when the page content depends on the user that requested it, so we can deliver a static and customized page to each user.

SSR is a well-known feature used daily in frameworks like Next.js, which Gatsby finally implemented. Now developers using Gatsby have an enormous range of options to deliver pages to users, either with Static Site Generation, Deferred Site Generation, Server-Side Rendering, or even — if you are brave enough — with Client-Side Rendering.

Parallel Query Running #

Besides the new rendering options, Gatsby still brings a lot of other features to improve performance and developer experience. As previously mentioned, one of the major drawbacks JAMstack and static sites had was their long building times. In addition to incremental building and DSG, Gatsby 4 introduces Parallel Query Running to diminish build time even more.

As you may know, Gatsby uses a data layer to group external data and then query it onto your site. Sourcing the data from your content sources into the data layer is relatively easy and fast. However, the process of querying the data from the data layer and querying it into the pages is pretty time-consuming. This step is called query running, which happens in the middle of the build and is the longest by far, taking around 40% of the build time.

Query running only was able to use one of the cores of the CPU, so all the queries had to be done one at a time. But in Gatsby 4, the entire way data was handled was changed since it migrated from Redux to its own in-memory data store and switched to lmdb-js.

“Lmdb-js is an ultra-fast NodeJS and Deno interface to LMDB; probably the fastest and most efficient key-value/database interface that exists for storage and retrieval of structured JS data.”

With this new architecture, all queries can be done across all available cores, which leads to immensely faster build times.

Build Time Optimization #

Lastly, both a little and big change that may pass unnoticed between all the prior features is all the configurations and tweaks made to improve build times. One of the major reasons build times and even developer server starts were slow was due to an incorrect configuration of the local development environment or when Gatsby’s sites were deployed anywhere other than Gatsby Cloud.

The Gatsby team has changed several critical parts of Gatsby’s infrastructure across Gatsby 3 minor updates and is now in Gatsby 4 to reduce build and development times. I consider reducing development times a key change to enhance developer experience since it becomes tedious to restart and wait for the developer server each time you make a change that requires a restart to take effect.

More after jump! Continue reading below ↓

Meet Smashing Email Newsletter with useful tips on front-end, design & UX. Subscribe and get “Smart Interface Design Checklists” — a free PDF deck with 150+ questions to ask yourself when designing and building almost anything.

Your (smashing) email

Once a week. Useful tips on front-end & UX. Trusted by 190.000 friendly folks.

Gatsby Cloud #

What’s Gatsby Cloud #

Even though Gatsby is known for being a framework, the Gatsby team offers other great products like Gatsby Cloud. Gatsby Cloud is a deployment service with an edge network dedicated uniquely to deploying Gatsby sites in a matter of minutes. It has been around for a long time and is very similar to Netlify. The service has been optimized only to build and host Gatsby sites, which means you can’t host Next.js, Vue, Angular, or Vanilla JS sites, but in exchange, Gatsby Cloud offers greatly faster build times for Gatsby sites.

Configuration #

The main advantage of using Gatsby Cloud to host your Gatsby project is the little to no configuration you need to start hosting it. It can host and run a Gatsby Project without configuration and supports all Gatsby’s new rendering features and more out of the box. As long as they are declared in your code, the server won’t have problems understanding and hosting your project. So, if you want to migrate from Gatsby 3 to 4, you may consider switching to Gatsby Cloud for your migration.

Build And Deployment Time #

As said before, a lot of people didn’t prefer Gatsby due to its long build times. But Gatsby Cloud brings even more features to make build times faster, and it has been configured to use all optimization features like incremental buildings, parallel querying, caching, and support pages using DSG to the point where a CMS update from Contentful on Gatsby’s 10,000-page site took around 10 seconds on average.

Besides build time, another aspect that has been drastically improved with Gatsby Cloud is deployment time. Deployment time is the time it takes to push your site onto the edge of the CDN, and it accounts for the final time between triggering a build and releasing your site to the world. It can take as much time as build time, to the point that deployment times for a medium-size static site of around 10,000 pages can take 2 to 10 minutes. But the same medium-size site takes, on average, a surprising 2-5 seconds in Gatsby Cloud.

Workflow #

Similar to Netlify, Gatsby Cloud workflow is based on Github, Gitlab, or BitBucket repositories. Gatsby Cloud fetches a Gatsby project from a repository, builds the site, and/or runs the server. And like many other services, you can enable automatic deployment when a branch changes in your repository. In case external data from a source like a CMS changes, Gatsby Cloud offers a build webhook to trigger a production build.

Other small workflow features I really liked were:

• Previewing
  It lets you create a preview site with all your changes and a shareable URL.
• Lighthouse Support
  It gives you a Lighthouse report every time a build is finished.

Gatsby Functions #

Lastly, we will see Gatsby’s serverless functions in action. They aren’t completely part of Gatsby Cloud since they can be deployed in Netlify too, but deploying Gatsby Functions is more straightforward in Gatsby Cloud. Now, what are Gatsby’s Functions? In simpler terms, they let you add an express-like backend to your Gatsby project to create an API, authenticate users, or submit forms.

Why would I want to create a backend in my Gatsby project? Most Gatsby use cases don’t require creating a backend or API. Still, in cases where there is more than one frontend application using the same data, it is a very good idea to decouple your data from your main frontend and make it accessible through an API, so it is accessed the same way with the same logic through all frontends. The power of Gatsby Functions is to have your backend hosted in the same place as your frontend, but they communicate headlessly through an API.

Gatsby Cloud vs. Netlify #

After seeing all the features offered by Gatsby Cloud, there isn’t a decisive factor in choosing one over another. Both of them offer pretty similar services and functionalities, and they come in a free tier, too. The main difference is that you can only host a Gatsby project in Gatsby Cloud, but with Netlify, you can host projects using almost any library or framework you want, such as Next.js, create-react-app, Vue, Angular, etc. So, in case you want to host a Gatsby project, I would recommend Gatsby Cloud since it is amazingly optimized and guarantees good results.

• 
  100+ fully native Angular components trusted by over 3M developers.
  Start free Trial

Gatsby 4 vs. Next.js #

In the SSR ecosystem, the clear dominant player has been Next.js, and many comparisons between Gatsby and Next.js ended by saying that Next.js offered SSR and Gatsby did not. And even though Gatsby was still extremely useful and effective, the fact that it didn’t support SSR was a decisive factor when choosing a framework to use. But the introduction of Gatsby 4 changed the game completely.

Since this article is dedicated to Gatsby’s new features, I will try not to focus too much on Next.js features. Still, I will say that Next.js and Gatsby currently offer similar functionality, and we can achieve almost the same results with both frameworks. However, there are still a lot of factors and features to consider when choosing one framework or the other. Gatsby offers features that Next.js doesn’t, like Deferred Static Generation, a data layer, and an enormous plugin library. On the same note, Next.js offers Incremental Static Regeneration and Server Components which is currently on alpha.

You can achieve the same user experience with both frameworks, and they will help you make beautiful websites. So, to choose a framework, I strongly believe the developer experience is the decisive factor. I feel Gatsby offers a better DX due to its awesome data layer that lets developers source their data and keeps it all in the same place, so it can be queried the same way. Another reason is its plugin library, which lets you add out-of-the-box support to CMS, internalization, e-commerce, analytics, offline support, et cetera. These are life-saving features that have helped me quickly start working on a new project.

Conclusion #

After seeing all the new features of Gatsby 4, we can confidently say that the future of Gatsby is already looking great! It is clear that the Gatsby team has been pretty self-critical and has heard its community since all Gatsby 4 features were wanted by the community for a long time. Therefore, I am pretty confident that Gatsby will keep following this path, and we will have many other cool features in the future.

Even though I might sound like a Gatsby salesman, I don’t consider it the best framework, just one that is completely worth experimenting with. Next.js is vastly more used among the SSR ecosystem, and the community believes it gives a better developer experience than Gatsby, but with Gatsby 4 this trend may change a little. It isn’t putting Next.js out of business any time soon, but thanks to its new rendering options, Gatsby 4 will clearly be on your list of frameworks to try out on your next project.

Gatsby Serverless Functions And The International Space Station

 Gatsby recently announced the launch of “functions”. In this article, Paul Scanlon explains how to get the current location of the International Space Station (ISS) as it orbits the Earth in realtime using Gatsby Functions and then display it 

a 3D interactive globe using React Three Fibre. 

Gatsby recently announced the launch of Functions which opens up a new dimension of possibilities — and I for one couldn’t be more excited! With Gatsby now providing Serverless Functions on Gatsby Cloud (and Netlify also providing support via @netlify/plugin-gatsby), the framework that was once misunderstood to be “just for blogs” is now more than ever, (in my opinion) the most exciting technology provider in the Jamstack space.

Getting Started #

With Gatsby Functions, you can create more dynamic applications using techniques typically associated with client-side applications by adding an api directory to your project and exporting a function, e.g.

|-- src
  |-- api
     -- some-function.js
  |-- pages

// src/api/some-function.js
export default function handler(req, res) {
  res.status(200).json({ hello: `world` })
}

If you already have a Gatsby project setup, great! but do make sure you’ve upgraded Gatsby to at least version v3.7

npm install gatsby@latest --save

If not, then feel free to clone my absolute bare-bones Gatsby starter repo: mr-minimum.

Before I can start using Gatsby Functions to track the International Space Station, I first need to create a globe for it to orbit.

Step 1: Building The 3D Interactive Globe #

I start by setting up a 3D interactive globe which can be used later to plot the current ISS location.

Install Dependencies #

npm install @react-three/fiber @react-three/drei three three-geojson-geometry axios --save

Create The Scene #

Create a new file in src/components called three-scene.js

// src/components/three-scene.js
import React from 'react';
import { Canvas } from '@react-three/fiber';
import { OrbitControls } from '@react-three/drei';

const ThreeScene = () => {
  return (
    <Canvas
      gl={{ antialias: false, alpha: false }}
      camera={{
        fov: 45,
        position: [0, 0, 300]
      }}
      onCreated={({ gl }) => {
        gl.setClearColor('#ffffff');
      }}
      style={{
        width: '100vw',
        height: '100vh',
        cursor: 'move'
      }}
    >
      <OrbitControls enableRotate={true} enableZoom={false} enablePan={false} />
    </Canvas>
  );
};

export default ThreeScene;

The above sets up a new <Canvas /> element and can be configured using props exposed by React Three Fibre.

Elements that are returned as children of the canvas component will be displayed as part of the 3D scene. You’ll see above that I’ve included <OrbitControls /> which adds touch/mouse interactivity allowing users to rotate the scene in 3D space

Ensure ThreeScene is imported and rendered on a page somewhere in your site. In my example repo I’ve added ThreeScene to index.js:

// src/pages/index.js
import React from 'react';

import ThreeScene from '../components/three-scene';

const IndexPage = () => {
  return (
    <main>
      <ThreeScene />
    </main>
  );
};

export default IndexPage; 

This won’t do much at the moment because there’s nothing to display in the scene. Let’s correct that!

Create The Sphere #

Create a file in src/components called three-sphere.js:

// src/components/three-sphere.js
import React from 'react';

const ThreeSphere = () => {
  return (
    <mesh>
      <sphereGeometry args={[100, 32, 32]} />
      <meshBasicMaterial color="#f7f7f7" transparent={true} opacity={0.6} />
    </mesh>
  );
};

export default ThreeSphere;

If the syntax above looks a little different to that of the Three.js docs it’s because React Three Fibre uses a declarative approach to using Three.js in React.

A good explanation of how constructor arguments work in React Three Fibre can be seen in the docs here: Constructor arguments

Now add ThreeSphere to ThreeScene:

// src/components/three-scene.js import React from 'react'; import { Canvas } from '@react-three/fiber'; import { OrbitControls } from '@react-three/drei'; + import ThreeSphere from './three-sphere'; const ThreeScene = () => { return ( <Canvas gl={{ antialias: false, alpha: false }} camera={{ fov: 45, position: [0, 0, 300] }} onCreated={({ gl }) => { gl.setClearColor('#ffffff'); }} style={{ width: '100vw', height: '100vh', cursor: 'move' }} > <OrbitControls enableRotate={true} enableZoom={false} enablePan={false} /> + <ThreeSphere /> </Canvas> ); }; export default ThreeScene; 

Not very exciting, ay? Let’s do something about that!

Create The Geometry (To Visualize The Countries Of Planet Earth) #

This next step requires the use of three-geojson-geometry and a CDN resource that contains Natural Earth Data. You can take your pick from a full list of suitable geometries here.

I’ll be using admin 0 countries. I chose this option because it provides enough geometry detail to see each country, but not so much that it will add unnecessary strain on your computer’s GPU.

Now, create a file in src/components called three-geo.js:

// src/components/three-geo.js
import React, { Fragment, useState, useEffect } from 'react';
import { GeoJsonGeometry } from 'three-geojson-geometry';
import axios from 'axios';

const ThreeGeo = () => {
const [isLoading, setIsLoading] = useState(true);
  const [geoJson, setGeoJson] = useState(null);
 
  useEffect(() => {
    axios
      .get(
   'https://d2ad6b4ur7yvpq.cloudfront.net/naturalearth-3.3.0/ne_110m_admin_0_countries.geojson'
      )
      .then((response) => {
        setIsLoading(false);
        setGeoJson(response.data);
      })
      .catch((error) => {
        console.log(error);
        throw new Error();
      });
  }, []);

  return (
    <Fragment>
      {!isLoading ? (
        <Fragment>
          {geoJson.features.map(({ geometry }, index) => {
            return (
              <lineSegments
                key={index}
                geometry={new GeoJsonGeometry(geometry, 100)}
              >
                <lineBasicMaterial color="#e753e7" />
              </lineSegments>
            );
          })}
        </Fragment>
      ) : null}
    </Fragment>
  );
};

export default ThreeGeo;

There’s quite a lot going on in this file so I’ll walk you through it.

1. Create an isLoading state instance using React hooks and set it to true. This prevents React from attempting to return data I don’t yet have.
2. Using a useEffect I request the geojson from the CloudFront CDN.
3. Upon successful retrieval I set the response in React state using setGeoJson(...) and set isLoading to false
4. Using an Array.prototype.map I iterate over the “features” contained within the geojson response and return lineSegments with lineBasicMaterial for each geometry
5. I set the lineSegments geometry to the return value provided by GeoJsonGeomtry which is passed the “features” geometry along with a radius of 100.

(You may have noticed I’ve used the same radius of 100 here as I’ve used in the sphereGeometry args in three-sphere.js. You don’t have to set the radius to the same value but it makes sense to use the same radii for ThreeSphere and ThreeGeo.

If you’re interested to know more about how GeoJsonGeometry works, here’s the open-source repository for reference: https://github.com/vasturiano/three-geojson-geometry. The repository has an example directory however, the syntax is slightly different from what you see here because the examples are written in vanilla JavaScript not React.

Combine The Sphere And Geometry #

Now it’s time to overlay the geometry on top of the blank sphere: Add ThreeGeo to ThreeScene

// src/components/three-scene.js
import React from 'react';
import { Canvas } from '@react-three/fiber';
import { OrbitControls } from '@react-three/drei';

import ThreeSphere from './three-sphere';
+ import ThreeGeo from './three-geo';


const ThreeScene = () => {
  return (
    <Canvas
      gl={{ antialias: false, alpha: false }}
      camera={{
        fov: 45,
        position: [0, 0, 300]
      }}
      onCreated={({ gl }) => {
        gl.setClearColor('#ffffff');
      }}
      style={{
        width: '100vw',
        height: '100vh',
        cursor: 'move'
      }}
    >
      <OrbitControls enableRotate={true} enableZoom={false} enablePan={false} />
      <ThreeSphere />
+      <ThreeGeo />
    </Canvas>
  );
};

You should now be looking at something similar to the image below.

Exciting Three.js sphere displaying the countries of the world (Large preview)

Now that’s slightly more exciting!

Step 2: Building A Serverless Function #

Create A Function #

This next step is where I use a Gatsby Function to request data from Where is ISS at, which returns the current location of the International Space Station.

Create a file in src/api called get-iss-location.js:

// src/api/get-iss-location.js
const axios = require('axios');

export default async function handler(req, res) {
  try {
    const { data } = await axios.get(
      'https://api.wheretheiss.at/v1/satellites/25544'
    );

    res.status(200).json({ iss_now: data });
  } catch (error) {
    res.status(500).json({ error });
  }
}

This function is responsible for fetching data from api.whereistheiss.at and upon success will return the data and a 200 status code back to the browser.

The Gatsby engineers have done such an amazing job at simplifying serverless functions that the above is all you really need to get going, but here’s a little more detail about what’s going on.

• The function is a default export from a file named get-iss-location.js;
• With Gatsby Functions the filename becomes the file path used in a client-side get request prefixed with api, e.g. /api/get-iss-location;
• If the request to “Where is ISS at” is successful I return an iss_now object containing data from the Where is ISS at API and a status code of 200 back to the client;
• If the request errors I send the error back to the client.

Step 3: Build The International Space Station #

Creating The ISS Sphere #

In this next step, I use Gatsby Functions to position a sphere that represents the International Space Station as it orbits the globe. I do this by repeatedly calling an axios.get request from a poll function and setting the response in React state.

Create a file in src/components called three-iss.js

// src/components/three-iss.js
import React, { Fragment, useEffect, useState } from 'react';
import * as THREE from 'three';
import axios from 'axios';

export const getVertex = (latitude, longitude, radius) => {
  const vector = new THREE.Vector3().setFromSpherical(
    new THREE.Spherical(
      radius,
      THREE.MathUtils.degToRad(90 - latitude),
      THREE.MathUtils.degToRad(longitude)
    )
  );
  return vector;
};

const ThreeIss = () => {
  const [issNow, setIssNow] = useState(null);

  const poll = () => {
    axios
      .get('/api/get-iss-location')
      .then((response) => {
        setIssNow(response.data.iss_now);
      })
      .catch((error) => {
        console.log(error);
        throw new Error();
      });
  };

  useEffect(() => {
    const pollInterval = setInterval(() => {
      poll();
    }, 5000);

    poll();
    return () => clearInterval(pollInterval);
  }, []);

  return (
    <Fragment>
      {issNow ? (
        <mesh
          position={getVertex(
            issNow.latitude,
            issNow.longitude,
            120
          )}
        >
          <sphereGeometry args={[2]} />
          <meshBasicMaterial color="#000000" />
        </mesh>
      ) : null}
    </Fragment>
  );
};

export default ThreeIss;

There’s quite a lot going on in this file so I’ll walk you through it.

1. Create an issNow state instance using React hooks and set it to null. This prevents React from attempting to return data I don’t yet have;
2. Using a useEffect I create a JavaScript interval that calls the poll function every 5 seconds;
3. The poll function is where I request the ISS location from the Gatsby Function endpoint (/api/get-iss-location);
4. Upon successful retrieval, I set the response in React state using setIssNow(...);
5. I pass the latitude and longitude onto a custom function called getVertex, along with a radius.

You may have noticed that here I’m using a radius of 120. This does differ from the 100 radius value used in ThreeSphere and ThreeGeo. The effect of the larger radius is to position the ISS higher up in the 3D scene, rather than at ground level — because that’s logically where the ISS would be, right?
100 has the effect of the sphere and geometry overlapping to represent Earth, and 120 for the ISS has the effect of the space station “orbiting” the globe I’ve created.

One thing that took a bit of figuring out, at least for me, was how to use spherical two dimensional coordinates (latitude and longitude) in three dimensions, e.g. x,y,z. The concept has been explained rather well in this post by Mike Bostock.

The key to plotting lat / lng in 3D space lies within this formula… which makes absolutely no sense to me!

x=rcos(ϕ)cos(λ)
y=rsin(ϕ)
z=−rcos(ϕ)sin(λ)

Luckily, Three.js has a set of MathUtils which I’ve used like this:

• Pass the latitude, longitude and radius into the getVertex(...) function
• Create a new THREE.Spherical object from the above named parameters
• Set the THREE.Vector3 object using the Spherical values returned by the setFromSpherical helper function.

These numbers can now be used to position elements in 3D space on their respective x, y, z axis — phew! Thanks, Three.js!

Now add ThreeIss to ThreeScene:

import React from 'react';
import { Canvas } from '@react-three/fiber';
import { OrbitControls } from '@react-three/drei';

import ThreeSphere from './three-sphere';
import ThreeGeo from './three-geo';
+ import ThreeIss from './three-iss';

const ThreeScene = () => {
  return (
    <Canvas
      gl={{ antialias: false, alpha: false }}
      camera={{
        fov: 45,
        position: [0, 0, 300]
      }}
      onCreated={({ gl }) => {
        gl.setClearColor('#ffffff');
      }}
      style={{
        width: '100vw',
        height: '100vh',
        cursor: 'move'
      }}
    >
      <OrbitControls enableRotate={true} enableZoom={false} enablePan={false} />
      <ThreeSphere />
      <ThreeGeo />
+     <ThreeIss />
    </Canvas>
  );
};

export default ThreeScene; 

The poll function will repeatedly call the Gatsby Function, which in turn requests the current location of the ISS and re-renders the React component each time a response is successful. You’ll have to watch carefully but the ISS will change position ever so slightly every 5 seconds.

The ISS is traveling at roughly 28,000 km/h and polling the Gatsby Function less often would reveal larger jumps in position. I’ve used 5 seconds here because that’s the most frequent request time as allowed by the Where is ISS at API

You might have also noticed that there’s no authentication required to request data from the Where is ISS at API. Meaning that yes, technically, I could have called the API straight from the browser, however, I’ve decided to make this API call server side using Gatsby Functions for two reasons:

1. It wouldn’t have made a very good blog post about Gatsby Functions if i didn’t use them.
2. Who knows what the future holds for Where is ISS at, it might at some point require authentication and adding API keys to server side API requests is pretty straightforward, moreover this change wouldn’t require any updates to the client side code.

Step 4: Make It Fancier! (Optional) #

I’ve used the above approach to create this slightly more snazzy implementation: https://whereisiss.gatsbyjs.io,

In this site I’ve visualized the time delay from the poll function by implementing an Svg <circle /> countdown animation and added an extra <circle /> with a stroke-dashoffset to create the dashed lines surrounding it.

Step 5: Apply Your New Geo Rendering Skills In Other Fun Ways! #

I recently used this approach for plotting geographical locations for the competition winners of 500 Bottles: https://500bottles.gatsbyjs.io. A limited edition FREE swag giveaway I worked on with Gatsby’s marketing team.

You can read all about how this site was made on the Gatsby blog: How We Made the Gatsby 500 Bottles Giveaway

In the 500 Bottles site I plot the geographical locations of each of the competition winners using the same method as described in ThreeIss, which allows anyone visiting the site to see where in the world the winners are.

Closing Thoughts

Gatsby Functions really open up a lot of possibilities for Jamstack developers and never having to worry about spinning up or scaling a server removes so many problems leaving us free to think about new ways they can be used.

 

 

Further Reading #

• If you’re interested in learning more about Gatsby Functions, I highly recommend Summer Functions, a five week course run by my good chum Benedicte Raae.
• In a recent FREE Friday night Summer Functions webinar we created an emoji slot machine which was super fun:
• Build an emoji slot machine with a #GatsbyJS Serverless Function · #GatsbySummerFunctions
• You might also be interested in the following episode from our pokey internet show Gatsby Deep Dives where Kyle Mathews (creator of Gatsby) talks us through how Gatsby Functions work:
  
• Gatsby Serverless Functions 💝 — Are we live? with Kyle Mathews