General

Building a Bot to Fetch Discord Scheduled Events with 11ty and Netlify

Oct 3, 2022

9 min read

If you haven’t heard of 11ty (Eleventy) yet, we are here to share why you should be excited about this new-ish static site generator on the block!

For clarification, a static site generator (SSG) is a tool that generates a static HTML website based on raw data and a set of templates.

11ty is an SSG with a small bundle size and no runtime, which means it only ships your code to the browser. It supports multiple templating engines providing flexibility to use templating languages like njk, .html, .md, and more. For this article, we will be using nunjucks (.njk) templating.

It’s worth pointing out that 11ty is NOT a javascript framework.

This article is a recap of the JS Drop training by Domitrius Clark where he showed us how to build a Discord Scheduled Event List with 11ty and Netlify.

In this workshop, you will learn how to build a static generated site for a list of scheduled events fetched from a Discord server using 11ty and Netlify.

A Notion document outlining the steps for this workshop. (Thanks Dom!)

👋 Before getting into the steps, make sure you have:

A GitHub account and a repo created to house your workshop code
A Discord account & a server for us to connect your bot to
A Netlify account to deploy your application at the end

Initial Project Scaffold and Install Dependencies

npm init -y to init a package.json with default values yarn add -D @11ty/eleventy @netlify/functions tailwindcss node-fetch@2 dotenv npm-run-all Open the new project in your favorite code editor Edit the script property of the package.json file:

"scripts": {
	"dev:css": "npx tailwindcss -i src/styles.css -o dist/styles.css -w",
"dev:11ty": "eleventy --config=_eleventy/config.js --serve --watch",
 	"dev": "node_modules/.bin/run-p dev:*",
"build:css": "NODE_ENV=production npx tailwindcss -i src/styles.css -o dist/styles.css -m",
"build:11ty": "eleventy --config=_eleventy/config.js --output=dist",
"build": "node_modules/.bin/run-s build:*"
}

The above scripts are the build commands for 11ty production, CSS build for Tailwind, and also to run the dev server for testing our application.

Now that we have our packages and scripts defined, let’s scaffold out the folders and files we’ll need for the site.

First edit the .gitignore:

yarn.lock
/node_modules
/dist
.env
# Local Netlify folder
.netlify

Next, define the 11ty configs:

Types of templating files (Nunjucks)
Directories to use include build output, where get components, layouts, and includes.
Defining plugins

Edit the _eleventy/config.js file with the following:

const {EleventyServerlessBundlerPlugin} = require("@11ty/eleventy")

module.exports = function (eleventyConfig) {
eleventyConfig.addPlugin(EleventyServerlessBundlerPlugin, {
    name: "events",
    functionsDir: './netlify/functions',
    redirects: "netlify-toml-builders"
});

	return {
		templateFormats: ['njk'],
		dir: {
			input: "src",
			output: "dist",
			includes: "_includes"
		},
		htmlTemplateEngine: "njk",
		dataTemplateEngine: "njk"
	}
}

Next, we edit the netlify config file netlify.toml to config Netlify deployment with the following:

Build commands
Path to Netlify functions

[build]
command = "npm run build"
publish = "dist"

[functions]
directory = "/netlify/functions"

Creating base layout and setting up Tailwind

We created the _includes folder with two sub-folders, for our components (or macros), simply named components and layouts, which is where we’re going to be focused in this lesson.

11ty exposes the _includes folders so that we have access to our layouts and components inside of our pages and inside of each other (for example using macros inside of other macros).

Let’s go ahead and create the HTML scaffold for our pages. Inside of /src/_includes/layouts/ we’ll create the base.njk file.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <link rel="stylesheet" href="/styles.css" />

  <title>{{ title }}</title>
</head>
<body class="w-screen h-screen bg-slate-400 flex flex-col text-gray-800 align-center justify-center">  
  <div class="flex flex-col w-screen h-screen">
    <main>
      {{ content | safe }}
    </main>
  </div>
</body>
</html>

The layout will be used to wrap all of our pages. We can also create sub-layouts and new layouts depending on the needs of the page. For this tutorial we will need only this base layout.

For the base.njk we:

We made the Tailwind styles visible to our page by adding a link tag for /styles.css
We are using the title variable, because of 11ty’s data cascade, and we’re able to pull variables in from our pages frontmatter. In our files, we’ll need to define a title to ensure our layout doesn’t break.
Notice the {{ content | safe }}. The content variable is the page content itself. So, in our case, this will be our .njk page and components. the safe variable is a builtin filter to nunjucks, to make sure it will not be HTML escaped.

Next, we will modify tailwind.config.js to make our Tailwind work as expected:

// tailwind.config.js

module.exports = {
	content: [
		"./src/**/*.{njk,md,html}",
		"./src/_includes/**/*.njk"
	]
}

And modify the styles.css file to import Tailwind utilities, base, and components:

@tailwind base;
@tailwind components;
@tailwind utilities;

Then we edit the index.njk file with the default content and frontmatter:

---
title: Homepage
layout: layouts/base.njk
---

<h1>Welcome</h1>

Now to test that everything works, start the dev server:

yarn dev

Everything should work!

Now navigate to http://localhost:8080 in your browser.

Let's create a Navbar component for our layout with Nunjucks, in the src/_includes/components/ add a navbar.njk:

{% 
  set linkList = [
    {'text': 'Home','url': '/'},
    {'text': 'Events','url': '/events/'}
  ] 
%}

<nav class="h-10 w-full">
  <ul class="flex p-7 gap-4 under items-center w-full h-full bg-neutral-800 text-gray-300 ">
    {% for link in linkList  %}
      <li class="hover:text-purple-600">
        <a class="{{ 'underline underline-offset-2' if link.url === page.url }}" href="{{ link.url }}">{{ link.text }}</a>
      </li>  
    {% endfor %}
  </ul>
</nav>

Next, we modify the index.njk file to include the navbar in our pages and add:

 {% include "components/navbar.njk" %}

Now the final document should look like this:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <link rel="stylesheet" href="/styles.css" />

  <title>{{ title }}</title>
</head>
<body class="w-screen h-screen bg-slate-400 flex flex-col text-gray-800 align-center justify-center">  
  <div class="flex flex-col w-screen h-screen">

    {% include "components/navbar.njk" %} 

    <main>
      {{ content | safe }}
    </main>
  </div>
</body>
</html>

Initialize a Discord BOT from the Discord server

Now that we have the template and base file set up, next we should connect the Discord bot to the page.

Before we start to initialize a discord bot, we need to put some things in place, so head over to your discord.

Go to the User Settings, navigate to the Advanced tab and enable the Developer Mode.

Head over to the Discord Developer Portal and click on New Application to create an application.

Fill in the necessary details and click on create.

On the sidebar menu, navigate to Bot and click on add bot.

We will need a few details for our app to connect with the Discord server.

Let’s copy them to the .env file.

Add environment variables DISCORD_BOT_TOKEN & DISCORD_GUILD_ID and assign the value for discord token from the Bot page by clicking reset token.

For the DISCORD_GUILD_ID, head over to a Discord server that you manage, or create one for this tutorial, side-click on the server and click on Copy ID.

Now paste the ID to set the value for the DISCORD_GUILD_ID environment variable. Next, add the bot to your server https://discordapp.com/api/oauth2/authorize?scope=bot&client_id=YOUR_CLIENT_ID

Find the client ID from the 0Auth2 tab and click on copy.

Now we are all set and connected to the server.

Using global data files in 11ty to fetch scheduled events from Discord

In 11ty, data is merged from multiple different sources before the template is rendered. The data is merged in what 11ty calls the Data Cascade.

We will be fetching data from discord from a javascript function in the global data file. Inside of src/_data, create a new file named events.js.

Previously, we created environment variables called DISCORD_BOT_TOKEN & DISCORD_GUILD_ID. Now, we can fetch our events endpoint, grab our events, and inject them into our templates.

Our file will look like this:

// src/_data/events.js

const fetch = require('node-fetch');
require("dotenv").config();

module.exports = async function () {
  const res = await fetch(`https://discord.com/api/v9/guilds/${process.env.DISCORD_GUILD_ID}/scheduled-events`, {
    method: "GET",
    headers: {
      "Authorization": `Bot ${process.env.DISCORD_BOT_TOKEN}`,
    }
  })

  const data = await res.json()

	console.log({data});

  return data
}

Creating the events page

In the src directory, create an events.njk file:

{# src/events.njk #}

<div class="flex flex-col items-center justify-center mt-10">
  <div class="flex flex-col">
     <h1>Discord Community Events</h1>
     <p class="animate-pulse">Served via On Demand Builders</p>
  </div>
</div>

Currently we’ve just got a page rendering some static content. Let’s use Nunjucks loops to render a card for each of our events.

The data we care about right now from the large event object coming back are:

creator
name
scheduled start time
description
and if it’s not inside of Discord, where is it

We also need to make sure we check the event for any meta data that could point us toward an external link for this event. Thankfully, this is another quick fix with Nunjucks if blocks.

Our final card (should) end up looking something like below.

{% for event in events %}
	<div class="border-4 border-pink-700 rounded-md p-5 mt-5">
    <div class="flex items-center">
      <div class="ml-3">
        <p class="text-sm leading-5 font-medium text-gray-900">Created by: {{ event.creator.username }}</p>
        <div class="flex text-sm leading-5 text-gray-500">
          <time datetime="2020-03-16">{{ event.scheduled_start_time }}</time>
        </div>
      </div>
    </div>
    <div class="mt-3 text-sm leading-5 text-gray-900">
      <p>Title: {{ event.name }}</p>
      </div>
    <div class="mt-3 text-sm leading-5 text-gray-900">
      Description: {{ event.description }}
    </div>

    {% if event.entity_metadata %}
      <div class="mt-3 text-sm leading-5 text-gray-900">
        <a href={{ event.entity_metadata.location }}>Where: {{ event.entity_metadata.location }}</a>
      </div>
    {% endif %}
  </div>
{% endfor %}

Before we test the application, schedule a test event on Discord, restart the dev server, then click on events tab in the navbar:

You should see your newly scheduled events.

Pushing to GitHub and deploying to Netlify

Pushing to Github

Let’s initialize a repo so we can track our changes and deploy live to the web as we go.

Start off with a quick command to initialize the repo:

git init

Then let’s get all of our current changes added and pushed to main, so we can create a repo.

git add .
git commit -m "Initial commit"

Using the GitHub CLI, create a repo and push it,

gh repo create 11ty-events-practice -s=. -r=upstream --public --push

This will create your repo, name it, and push up the commits all in one command.

To confirm that the repo is up, run:

gh repo view -w

Deploy to Netlify

To create a new project on Netlify with the new repo as the base, run:

netlify init

Fill in the prompts. You should be asked the following:

Choosing to create and configure a new site
Choose your team
Set your unique site name

Now, you should have an admin URL and base URL link in the console.

There will be a few more prompts:

Authenticate Github through Netlify
leave build command blank
leave netlify functions folder blank

Once all that is done, we’re going to want to run a few commands:

git push
netlify open

If something was wrong with your initial linking of your code, try to run a new production deploy using:

netlify deploy --prod

Netlify CLI will deploy the local project to the Netlify server and generate a random URL which you can visit to see the live app.

Conclusion

In this workshop, you learned to use 11ty to fetch and display your scheduled events from a discord server and deploy an app to Netlify. That was pretty easy! Did you run into any issues?

There is more! Watch the full training on the ThisDot YouTube Channel

Are you excited about 11ty? What are you building using it? Tell us what excites you!

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.

Hassan Sani

@inidaname @inidaname

How to Create Better Test Coverage Using Cypress 10

Testing is an integral part of software development, and it is important that all developers learn best testing practices. Jordan Powell, DX engineer at Cypress and Angular Google Developer Expert, has some tips to share with developers on how to write better tests using Cypress 10. In this article, we will take a look at Powell’s tips for writing end-to-end tests, component tests, and advanced testing patterns in Cypress. If you want to learn more from Jordan Powell, please check out his Advanced Cypress JS Drop training. Table of Contents - Why is Testing important? - Types of Testing - A new take on the testing pyramid - Differences between end-to-end testing and component testing - Jordan Powell’s best practices for E2E testing - Don’t use HTML Native selectors - Use Closures - Independent Test - Use Route Aliases - Setting a Global baseUrl - Jordan Powell’s Best Practices for Component Testing - Default Config Mount - Cypress Intercept - Use createOutputSpy - Jordan Powell’s Advanced Cypress Patterns - Session - Origin - Conclusion Why is Testing important? Software testing identifies issues within the application, and helps ensure that only high quality products are shipped to the user. Here are Jordan Powell’s reasons on why testing is important, and how it helps developers: Documentation: Good testing coverage will result in developers creating stronger test plans and better QA testing for new releases. Confidence: Writing good tests allows developers to build new features in confidence because the applications are working as intended. Safe Refactoring: Good test coverage leads to less refactoring down the road, and provides developers more time to work on new features. Improved UX: Good test coverage provides better UX (User Experience) for the end user because the application is working as intended. Types of Testing E2E, Integration, and Unit testing are three common methods for testing software applications. Unit Test: Unit testing serves as the foundation of the test pyramid. If you're working in a functional language, a unit will most likely be a single function. Your unit tests will call a function with different parameters and ensure that it returns the expected values. In an object-oriented language, a unit can range from a single method to an entire class. Integration test: Integration testing is where individual components of your application are tested as a group. End-to-end testing: E2E Testing is a technique that tests your app from the web browser through to the back end of your application, as well as testing integrations with third-party APIs and services. These types of tests are great at making sure your entire app is functioning as a cohesive whole. A new take on the testing pyramid In Jordan Powell’s Advanced Cypress JS Drop training, he challenges developers to rethink the traditional testing pyramid, and believes that component testing should also be included. Component Testing with Cypress 10 allows developers to test individual components quickly, regardless of its complexity. Component tests differ from end-to-end tests in that instead of visiting a URL to pull up an entire app, a component can be "mounted" and tested on its own. Differences between end-to-end testing and component testing Here are a few key differences between End-to-end and component testing: | End-to-end testing | Component testing | | ------------------------------------------------------- | ------------------------------------------------------------------------ | | The entire application and all of its layers are tested | Only the independent components are tested | | Testing can be done by developers and QA Teams | Testing is done by the developers | | Often requires a complex setup | No extra configuration for CI(Continuous Integration) environments needed | | Initialization command: cy.visit(url) | Initialization command: cy.mount() | Jordan Powell’s best practices for E2E testing Don’t use HTML Native selectors It is not good practice to use element selectors, id attributes, or class attributes when writing End-to-end tests. Using HTML Native selectors can lead to team members refactoring tests later on, or changing attributes which could affect the tests. Jordan Powell recommends using data attributes that can inform the team that this is a test attribute. When other team members need to change anything, they will be aware of the function of the attribute and what it may affect. Use Closures Jordan warns against assigned return values for Cypress assertions, and recommends using closures to access the Commands yield like this: ` Independent Test It is not good practice to combine related tests. Jordan Powell suggests that tests should be run independently from one another without sharing or relying on other test states. If test suites are related in any way, run the related properties or methods before each of the test runs, like in the code below: ` Use Route Aliases Another recommended practice is to use route aliases to guard Cypress against proceeding until an explicit condition is met. ` Setting a Global baseUrl It is bad practice to use hardcoded URL strings for the baseUrl because it will eventually fail when the environment changes. Instead, Powell recommends using a config file that holds the environment baseUrl. Jordan Powell’s Best Practices for Component Testing All of the code examples in this next section will be for Angular, but Cypress component testing works for all major Frontend JavaScript frameworks. Default Config Mount Component testing takes two parameters: the component to mount, and the object for configuration. A Custom Mount Config can boost flexibility. It ships a default mount config which you can use, but to manage multiple modules and import without adding too many boilerplate codes, it is recommended to have a custom mount config for specific instances. ` Cypress Intercept Component testing handles the individual components you are testing at a particular time, to access external API it is recommended to use cy.intercept. According to the Doc Cy.intercept can be used to passively listen for matching routes without manipulating the request or its response in any way. ` Use createOutputSpy When working with eventEmitter for components that may contain forms or other elements with events, createOutputSpy will automatically create an EventEmitter and set up the spy on it's .emit() method. ` Jordan Powell’s Advanced Cypress Patterns Session When testing for routes or components that require authentication Cypress provides cy.session which eliminates creating functions in your test to check for sessions on every call to the route or component. cy.session caches the sessions, and it will skip the login process for testing components that need the sessions on a second call. ` Origin Running tests for projects that require a visit to multiple different domains could get CORS, or a limitation of visits, due to browser environment. Cypress provides Origin to help bypass some of the browser limitations. ` Conclusion In this article, we looked at Jordan Powell’s tips for writing End-to-end tests, component tests, and advanced testing patterns in Cypress. I recommend watching the full video for Jordan Powell’s Advanced Cypress JS Drop training. Are you excited about the Cypress Component Testing? Let us know on Twitter....

Dec 19, 2022

6 mins

CypressTesting

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

Building a Bot to Fetch Discord Scheduled Events with 11ty and Netlify

Initial Project Scaffold and Install Dependencies

Creating base layout and setting up Tailwind

Creating a Navbar component in Nunjucks

Initialize a Discord BOT from the Discord server

Using global data files in 11ty to fetch scheduled events from Discord

Creating the events page

Pushing to GitHub and deploying to Netlify

Pushing to Github

Deploy to Netlify

Conclusion

Hassan Sani

You might also like

How to Create Better Test Coverage Using Cypress 10

Transforming Platform Engineering Through Chargeback Programs with Shuchi Mittal

You might also like

How to Create Better Test Coverage Using Cypress 10

Transforming Platform Engineering Through Chargeback Programs with Shuchi Mittal