Forem: Karin

Deploy your bolt.new app to Netlify

Karin — Tue, 03 Dec 2024 08:54:33 +0000

Have you tried Bolt.new? This AI-powered tool transforms your ideas into fully functional websites in minutes. Simply provide a short prompt, and Bolt takes care of the rest—generating the code for your site and making it effortless to create unique projects.

In this video, we explore how to create and deploy a fully functional website in just a few steps:

Generate your site: Provide a simple prompt—like creating a website celebrating cats! Bolt generates a beautiful application, complete with features like comments powered by Turo and Netlify Functions.
View your live site: Bolt automatically deploys your site to Netlify, giving you a live URL to share instantly.
Claim ownership: Transfer the site to your Netlify team and make it yours.
Link to GitHub: Open your project in StackBlitz, create a repository, and link it to your Netlify site for streamlined version control.

With Bolt and Netlify, turning ideas into live, production-ready sites has never been faster. What kind of website would you create? Share your ideas (and URLs) in the comments—we’d love to see them!

True color with an explainer on bits and bytes

Karin — Thu, 24 Oct 2024 19:52:18 +0000

In this article I'm going to talk about what it means when a terminal can render true color. We're going to be diving into bits and bytes and how they support RGB.

BUT I SEE YOUR TRUE COLORS, SHINING THROU... ahum oh wait I was gonna talk about rendering true colors... Not the hit song True Colors by Cyndi Lauper. As I dive into my journey of using LazyVim, I decided to take it a bit further and investigate some of the technologies that support it, LazyVim recommends using a "terminal that supports true color". Let's dive in.

Bits and Bytes

I want to talk about bits and bytes. If we understand how those work, we might be able to thoroughly understand true color as well.

Bit

A Bit stands for Binary Digit. It is the smallest unit available in computer science. It represents either 0 as off, or 1 as on. It acts like a little switch, like a light switch. The switch is either on or off. This means that a bit can represent only two things.

Bits help a computer keep track of things.

Byte

A byte consists of 8 bits. And because one bit can have two values (0 or 1) you can make a lot of combinations. In fact, you can make 256 combinations! How does that work?

Imagine you have two light switches, they allow four different combinations:

00 (both off)
01 (first off, second on)
10 (first on, second off)
11 (both on)

We can represent this as 2^2! Meaning 2 x 2.

If we had three light switches, we would get 8 possible combinations.

000 (all off)
001 (only the last one on)
010 (middle one on)
011 (middle and last on)
100 (first one on)
101 (first and last on)
110 (first and middle on)
111 (all on)

This would be represented as 2^3. Which is 2 x 2 x 2.
With bits, every time we add a bit, we double the amount of possible combinations. Because the amount of combinations multiplies by a constant factor we can conclude that we are talking about exponential growth.

Big deep breath. Ok we got there.

True color can render RGB

True color means being able to display a huge range of colors. In fact, it means that something can display more than 16 million colors. In order to support that amount of colors our computer needs to keep track of 24 bits because 2^24 equals:

2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2×2

So 2^24 = 16,777,216, which gives us over 16 million possible colors!

This means that we use 3 bytes (24/8 = 3) to represent one pixel of color. And this is where we get to RGB!

RGB

RGB is short for Red, Green and Blue. When we use RGB in programming we use 8 bits for each color. We define exactly how much Red, Green or Blue we want to see in each pixel.

Red: an intensity of 0 (completely off) to 255 (completely on)
Green: an intensity of 0 (completely off) to 255 (completely on)
Blue: an intensity of 0 (completely off) to 255 (completely on)

They work together very similar to how we perceive colors in the real world. It mixes the three primary colors that we have in light to create a wide range of options.

Let's look at it with an example of css:

Black: RGB(0, 0, 0) – No red, green, or blue (total absence of light).
White: RGB(255, 255, 255) – Maximum red, green, and blue (full intensity of all channels).
Pure Red: RGB(255, 0, 0) – Full red, no green or blue.
Pure Green: RGB(0, 255, 0) – Full green, no red or blue.
Pure Blue: RGB(0, 0, 255) – Full blue, no red or green.
Gray: RGB(128, 128, 128) – Equal intensity of red, green, and blue.

Pretty nifty right!

Conclusion

So... when something asks for a terminal that supports true color, it means that we need a terminal that is capable of using 24 bits for each pixel. This will allow for a larger range of colors than terminals that support only 8-bit (256 colors) or even fewer colors.

Netlify integrations can now inject serverless functions to enhance any site. Here’s how

Karin — Thu, 11 Apr 2024 12:01:24 +0000

It’s long been possible to use Netlify Functions in your site. But with the Netlify SDK we’re bringing the power of function injection to integration builders as well. This allows you to build one integration that can power any of your Netlify sites using Netlify Functions with the click of a button! This guide will show you three different types of functions you can inject into a site.

TL;DR

This guide explains the three different types of functions that you can inject into a site using a Netlify integration: serverless functions, scheduled functions and background functions (only available for sites that are on Core Pro and Core Enterprise plans). We'll make an integration by using the functions boilerplate from the Netlify CLI, and deploy it for use in an example site.

You can explore the full source code with examples to see how to inject each of these three types of functions. Or you can add this integration to your Netlify account by clicking the button below.

You can explore the full source code of this integration to see how we built this integration. Or add the integration to your Netlify account by clicking the button below.

Prerequisites

Let’s get started

First, run npm create @netlify/sdk@latest to create a new integration. Answer the prompts following the steps below.

? Where do you want to create the integration? sdk-sf-injection-integration
? What is the slug of the integration? (e.g. my-integration) sdk-sf-injection-integration
? Summarize what your integration does. This will be shown on the integration's card on the Integrations page. It has some examples for
injecting functions
? Which boilerplate should be included? Functions Injection (beta)
? What level will this integration be installed on? site (recommended for Build Event Handlers, Edge Functions and Functions)
? Which package manager do you want to use? pnpm
? Do you want to create or link a Netlify site to your integration? This will help you test your integration and will be used to host
your integration. skip

This will create your integration in the folder with the name you provided! It will have a scaffold that the SDK created for you. There is a basic structure there that looks like this:

├── integration.yaml
├── netlify.toml
├── node_modules
├── package-lock.json
├── package.json
├── src
│ ├── index.ts
│ └── functions
│   └── hello-world.mts
└── tsconfig.json

integration.yaml - The integration configuration file. This is where you configure the integration name, description, and other metadata.
netlify.toml - The Netlify configuration file. This is where you configure the settings for your integration.
src/index.ts - The entry point for developing the integration.
src/functions/ - The folder to store your functions in.
src/functions/hello-world.mts - An example function.

Deploy the integration

You have a working integration now! Follow this guide to deploy your integration to your Netlify account so we can try it out on a Netlify site.

After following that guide, let’s try it out on one of your Netlify sites! You can test it out by finding a site in your Netlify account (make a simple test site if necessary). When you’re in the dashboard of that site, select ‘integrations’ in the site’s sidebar. Then, find your integration in the list of private integrations. The last step is to click ‘enable’ on the integration card.

Test it out by redeploying your test site and visiting your site on the /.netlify/functions/sf_prefix_hello-world path. It should say Hello, world!.

Check out the integration code

Open up the src/index.ts file in your editor to see how the integration is set up. In that file you’ll see the following:

Test it out by redeploying your test site and visiting your site on the /.netlify/functions/sf_prefix_hello-world path. It should say Hello, world!.

Check out the integration code

Open up the src/index.ts file in your editor to see how the integration is set up. In that file you’ll see the following:

// src/index.ts
import { NetlifyIntegration } from "@netlify/sdk";

const integration = new NetlifyIntegration();

integration.addFunctions("./src/functions", {
  prefix: "my_unique_prefix",
});

export { integration };

The addFunctions method defines where the SDK can find your function. In this case it’s ./src/functions. It also provides a prefix for your functions. This is important because it helps avoid naming conflicts with functions that might be injected by other integrations or frameworks.

Different function options

Let’s dive into the different types of functions you can inject through the SDK: serverless functions, background functions and scheduled functions.

Serverless function

The first type is the one that is already part of the scaffold that the SDK created for you, a default serverless function.

What can you use a serverless function for?

These types of functions can be used for a lot of different usecases, some examples are fetching live data from an API, returning dynamic images, sending automated emails or validating user input.

How do you create a serverless function?

If we open the file src/functions/hello-world.mts in the integration’s repository we’ll see the following:

// Documentation: https://sdk.netlify.com

export default async () => {
  return new Response("Hello, world!");
};

You’re looking at the most basic version of a function. As mentioned before, this function can be found on the /.netlify/functions/my_unique_prefix_hello-world endpoint on sites where it is installed. You can change this path by adding a config to the file like this:

// Documentation: https://sdk.netlify.com

export default async () => {
  return new Response("Hello, world!");
};

export const config = {
  path: "/test",
};

How do you use a serverless function?

If you were to commit this change to your integration and push it with continuous deployment set up, it will automatically deploy the changes to your integration. When you try it out on your test site by redeploying your site, this function should be accessible through the /test endpoint.

Background function

Background functions can only be used on sites in teams that are on Core Pro or Core Enterprise plans, so keep this in mind if you’re planning on building that kind of integration.

What can you use a background function for?

A background function is useful if your integration needs to inject a function that has to run for longer than the 10 second maximum execution time permitted for regular serverless functions. A background function can run for up to 15 minutes and doesn’t need to complete before a visitor can take next steps on the site it is injected in. It can be used for tasks such as batch processing, scraping or for slower API workflow execution.

As mentioned in the background functions documentation, background functions are invoked asynchronously. They return an initial 202 success response and will then run in the background until it completes.

How do you create a background function?

Creating a background function works similar to normal functions, the only difference is that you append the name of the file with -background. Let’s create one!

First, let’s install a useful dependency with npm install @netlify/functions. Then, in your src/functions directory create a file called count-background.mts, add the following content:

import type { BackgroundHandler, HandlerEvent, HandlerContext } from "@netlify/functions";

export const handler: BackgroundHandler = (event: HandlerEvent, context: HandlerContext) => {
  const sleep = (ms: number) => {
    return new Promise((resolve) => setTimeout(resolve, ms));
  };

  (async () => {
    for (let i = 0; i <= 60; i++) {
      const date = new Date();
      await sleep(1000);
      console.log(date.toLocaleString(), i);
    }
    console.log("Done");
  })();
};

export const config = {
  path: "/count",
};

How do you use a background function?

This deploys to an endpoint at /count relative to the base URL of the site your integration is used on. When this function is invoked, the function returns an initial 202 success response. It will then log numbers 1 through 60. Try it out by committing it to your integration’s repository and pushing your changes. Your integration will redeploy, after this make sure to also redeploy your test site and call this new function.

Scheduled function

Scheduled functions are an exciting feature that makes it possible to run functions on a regular and consistent schedule, kind of like a cron job!

What can you use a scheduled function for?

Scheduled functions provide so many different possibilities! From invoke a set of APIs to collate data for a report at the end of every week to backing up data from one data store to another at the end of every night or building and/or deploying all your static content every hour instead of for every authored or merged pull request.

How do you create a scheduled function?

Creating a scheduled function works similar to normal functions, the only difference is that you export a config object from the file that defines when the function should run with something called a “cron expression”.

Create a new file in your src/functions directory called hourly-run.mts and add the following content:

import type { Config } from "@netlify/functions";

export default async (req: Request) => {
  const { next_run } = await req.json();

  console.log("Received event! Next invocation at:", next_run);

  return new Response("OK");
};

export const config: Config = {
  schedule: "* * * * *",
};

How do you use the scheduled function?

Commit it to your integration’s repository and push your changes. Your integration will redeploy, after this make sure to also redeploy your test site and call this new function. By going to your function logs you should be able to see an hourly message.

What’s next?

Go ahead and use all of these new possibilities to build something that your team can really use with a private integration! Create one integration and apply it to your different Netlify sites to automate your workflows. Happy coding!

More information

Create an integration that injects edge functions into any site

Karin — Wed, 03 Apr 2024 11:51:36 +0000

Netlify's edge functions have been a useful tool for developers wanting to add logic like transforming responses, setting custom request headers, localizing content based on the user's location, and more. But we also wanted to make it easy for integration developers to inject edge functions into the user's site. This expands the possibilities for what you can do with Netlify integrations and allow the creation of integrations that can modify the user's site at the edge.

TL;DR

In this guide you're going to use the Netlify SDK to create an integration that can block content based on the location of your site visitor. You'll create an integration that injects an edge function into the user's site that checks the user's location and blocks the content if they are in a specific country. You’ll then be able to use this integration on any of your Netlify sites by enabling and configuring them.

You can explore the full source code of this integration to see how we built this integration. Or add the integration to your Netlify account by clicking the button below.

Need full control on who gets to access your sites?

While this integration might provide some control already, if you’re looking for a full-fledged solution to control who can access your Netlify site, then take a look at Netlify Firewall Traffic Rules. This feature empowers Enterprise customers with Netlify High-Performance Edge to proactively control who can access their Netlify web properties based on the geographic location and IP address of the requestor, in real-time.

Prerequisites

Let's get started

First, run npm create @netlify/sdk@latest to create a new integration. Answer the prompts following the steps below. If you're using Visual Studio Code, you can configure it to use Edge Functions. This will install the Deno extension and create a new settings file for you.


? Where do you want to create the integration? NAME-OF-YOUR-INTEGRATION
? What is the slug of the integration? (e.g. my-integration) SLUG-OF-YOUR-INTEGRATION
? Summarize what your integration does. This will be shown on the integration's card on the Integrations page. DESCRIPTION-OF-YOUR-INTEGRATION
? Which boilerplate should be included? [more than one]
? Which boilerplate should be included? Integration UI, Edge Function Injection (beta)
? What level will this integration be installed on? site (recommended for Build Event Handlers and Edge Functions)
? Would you like to configure VS Code to use Edge Functions? yes
? Which package manager do you want to use? pnpm
? Do you want to create or link a Netlify site to your integration? This will help you test your integration and will be used to host your
integration. skip
? A new VS Code settings file will be created at /path/.vscode/settings.json yes
? The Deno VS Code extension is recommended. Would you like to install it now? yes

This will create your integration in the folder with the name you provided. The Netlify SDK will scaffold the basic structure needed for your integration and output the required files:

├── integration.yaml
├── netlify.toml
├── node_modules
├── package-lock.json
├── package.json
├── src
│ ├── index.ts
│ └── edge-functions
│   └── hello-world.ts
└── tsconfig.json

integration.yaml - The integration configuration file. This is where you configure the integration name, description, and other metadata.
netlify.toml - The Netlify configuration file. This is where you configure the settings for your integration.
src/index.ts - The entry point for developing the integration.
src/edge-functions/ - The folder to store your edge functions in.
src/edge-functions/hello-world.ts - An example edge function.

Deploy the integration

You have a working integration now! Let's try it out by deploying your integration as a private integration.

Now that you've created your private integration, let’s try it out on one of your Netlify sites! You can test it out by finding a site in your Netlify account (make a simple test site if necessary). When you’re in the dashboard of that site, select ‘integrations’ in the site’s sidebar. Then, find your integration in the list of private integrations. The last step is to click 'enable' on the integration card.

You can test it out by redeploying your site and then visiting your site on the /test path. You should see the message "Hello, world!".

Customizing

Now that you've seen your integration in action, let's look at the code and customize it so it can block content based on the location of your site visitor.

First let's look at the src/index.ts file. In there you can see that it creates a new NetlifyIntegration instance and calls the addEdgeFunctions method to define where the edge functions are located in the codebase. In this case it's ./src/edge-functions. It also provides a prefix for the edge functions. This is important because it helps avoid naming conflicts with edge functions that might be injected by other integrations or frameworks. Let's change that prefix from ef_prefix to block_content.

// src/index.ts
import { NetlifyIntegration } from "@netlify/sdk";

const integration = new NetlifyIntegration();

integration.addEdgeFunctions("./src/edge-functions", {
  prefix: "block_content",
});

export { integration };

This is step 1 in getting edge functions injected into the user's site. The next step is to define your edge function. In this case the boilerplate has already created an example edge function for you in the src/edge-functions/hello-world.ts file. Let's change this edge function's filename to block-content.ts and update the code to block content based on the user's location.

// src/edge-functions/block-content.ts

export default async (
  _request: Request,
  context: { geo: { country: { code: string; name: string } } }
) => {
  // Get the BLOCKED_COUNTRY_CODE from the site's environment variables.
  const BLOCKED_COUNTRY_CODE = Netlify.env.get('BLOCKED_COUNTRY_CODE');

  // Use context.geo to find the country code and name.
  const countryCode = context.geo?.country?.code;
  const countryName = context.geo?.country?.name';

  // Use the countryCode to check if we should block it.

  if (countryCode === BLOCKED_COUNTRY_CODE) {
    return new Response(
      `We're sorry, you can't access our content from ${countryName}!`,
      {
        headers: { 'content-type': 'text/html' },
        status: 451,
      }
    );
  }

  // Get the response of the original content that this path pointed to.
  // Learn more: https://docs.netlify.com/edge-functions/api/#use-conditional-request
  const response = await context.next();

  // Return the original response
  return new Response(response);
};

// This defines the path that this edge function will run on
// In this case, it runs on every path of the site.
export const config = {
  path: '/*',
};

As you can see, we are using the context.geo.country.code to get the country code of the user's location. We then compare this to the BLOCKED_COUNTRY_CODE environment variable. If the user is in the blocked country, we return a 451 status code with a message that they can't access the content. Otherwise, we return a 200 status code with a message that they can access the content.

Let's commit these changes to your integration and push it. If you've set up continuous deployment for your integration, it will automatically deploy the changes to your integration if you push the commit to your main branch.

Testing

Now on your test site, add the BLOCKED_COUNTRY_CODE environment variable with the country code you want to block. It might be interesting to try it with your own country code to see if it works. After you've added the environment variable, redeploy your site and visit it. You should see the message that you can't access the content from your country.

Add an integration UI

Do you want to go one level further with developer user experience? Try building your own integration UI that allows the developer to set the BLOCKED_COUNTRY_CODE environment variable. If you want to see an example of how this code could look, check out the readme of the repository to see how we built it in this example integration!

Other things to try and more information

If you want to know more about edge function injection through integrations, make sure to read the documentation! It walks you through the steps to create an integration that injects edge functions, but also explains more complex things like the order of execution for edge functions when injected into a user’s site through an integration, and how they interact with any user-defined edge functions.

Happy coding!

Find your module's location

Karin — Mon, 25 Mar 2024 00:00:00 +0000

Recently, I needed to create a node module that would copy a file from within the module into the repository that was using it. For this, I had to find the file's exact location within the node module. I needed to make sure that this script would work independently from where it was installed. Luckily, this is where import.meta.url came in.

`import.meta.url`

The very useful import.meta.url will return a string that contains the full URL to the module that it is being called from. As MDN mentions, when you are using this outside of the browser and in a Node.js environment, this will actually be a file path. In my case, I was dealing with a Node.js environment (which is older than Node.js v20), which is why I'll focus on that here.

`__dirname`

Some might wonder: why don't you just use __dirname? Well, if you want to use ES modules, this is simply not available. It means you're going to have to use import.meta.url instead. PLUS, you have to do some extra work as well. We'll get to that.

Why not just use `process.cwd()`?

If you use process.cwd(), you will actually get the directory where you started the process. In the case of using a module within a repository, it would mean that you would get the repository's directory, not the module's directory. And that is something we do not want here. This is why you need to use import.meta.url to get the module's actual directory.

Getting the actual directory

Speaking of, let's get that directory. So my file was inside of a foo folder (of course it wasn't, but let's pretend it was). I wanted to copy a file from within the foo folder to the repository that was using the module. I used import.meta.url which got me a filepath to the current module I was in.

I had to make sure that this filepath was a normal url first, which is where fileURLToPath from the url module came into play. After this, I passed this path to the dirname function (from the path module) to get the directory of the module. And voila. I had the directory of the module.

// In Node.js version 14.14 and up:

import { dirname } from 'node:path';
import { fileURLToPath } from 'node:url';

const moduleDirectory = dirname(fileURLToPath(import.meta.url));

Modern Node.js

With Node.js version 21.2, a new option called import.meta.dirname was introduced. While this only works for file modules, it would do the trick:

const moduleDirectory = import.meta.dirname;

Using the directory

Now that I had the directory, I could actually copy my files to the root folder of my repository. To do this I used the fs module to read the file and write it to the repository's directory. And this is also where process.cwd() came in.

import { readFileSync, writeFileSync } from 'node:fs';
import { dirname } from 'node:path';
import { fileURLToPath } from 'node:url';

const moduleDirectory = dirname(fileURLToPath(import.meta.url));

const file = readFileSync(`${moduleDirectory}/foo/file.txt`);
writeFileSync(`${process.cwd()}/file.txt`, file);

And that is how you can copy a file from within a module to the repository it's being used in. Voila!

Send data to a node.js server with FormData, a comprehensive guide.

Karin — Mon, 11 Mar 2024 00:00:00 +0000

There are many different ways to send data from an HTML form to a server. I wanted to provide a deep dive into using the FormData JavaScript interface for anyone who might have seen it before but hasn't had the chance to dive into it. In this article, you'll learn how the content type multipart/form-data differs in use from alternative content types, how the FormData interface works, how you can use it to send data to the server, and how you can write a simple server to receive and use the data.

Different content types for sending data

Let's look at the following piece of HTML:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>Simple Form</title>
  </head>
  <body>
    <form id="myForm">
      <label for="name">Name:</label>
      <input type="text" id="name" name="name" />

      <label for="favorite-food">Favorite food:</label>
      <input type="text" id="favorite-food" name="favorite-food" />

      <input type="submit" value="Submit" />
    </form>
  </body>
</html>

It has a form element with two inputs. Each is a text input. What are the different ways we could send the data from this form to a server?

`text/plain`

If you don't specify a Content-Type header, text/plain is the default. Here is an example of sending the data from the form above to a server using text/plain:

<script>
  document
    .getElementById('myForm')
    .addEventListener('submit', function (event) {
      event.preventDefault();

      var elements = this.elements;

      const data = [...elements]
        .reduce((acc, curr) => {
          if (curr.name) {
            acc.push(curr.name + '=' + curr.value);
          }
          return acc;
        }, [])
        .join('&');

      fetch('/api/endpoint', {
        method: 'POST',
        headers: {
          'Content-Type': 'text/plain',
        },
        body: data,
      });
    });
</script>

The data is sent as a string of query parameters. This is what the data would look like when it gets to the server:

'name=John&favorite-food=Pizza'

For most uses, you may have to add some code on the server to parse the query parameters. While there are more convenient ways of sending data, it sure is simple! (and sometimes, all you truly need…). The problem is that once you want to start sending different types of data, it becomes really unflexible. You can only send text data, and you cannot send files.

`application/x-www-form-urlencoded`

There is also the form element's default behavior, which is using the application/x-www-form-urlencoded content type. This happens when we add a method="post" attribute to the form element. When someone submits the form, the data is sent to the server as a string of query parameters. But unlike text/plain, it is actually sent in the body of the request.

A side effect is that the page will reload or navigate to whatever path is given in the action="/" attribute. This is standard behavior for HTML when submitting a form. The navigational side-effect can be prevented by using JavaScript by calling event.preventDefault() in the submit event listener.

This way of sending data has decreased in popularity with the rise of JavaScript frameworks. In modern web apps, developers tend to use JavaScript to send the data to a server, wanting to avoid navigating or reloading the page. Still, though, it's a very common way of sending data that is still used often.

To send the data from the form above to a server using application/x-www-form-urlencoded, we can change the code from the original form by adding the following additional attributes:

<form id="myForm" method="post" action="/"></form>

This would send the data from the inputs in the form with a POST method to the server residing at the root path /. This way of sending data also, by default, does not support uploading files.

`application/json`

With the rise of JavaScript frameworks and the need to send data to a server from within Single Page Applications (SPA's), the application/json content type is often used. This is how you could send data using the application/json content-type:

<script>
  document
    .getElementById('myForm')
    .addEventListener('submit', function (event) {
      event.preventDefault();

      var formData = {
        name: document.getElementById('name').value,
        favoriteFood: document.getElementById('favorite-food').value,
      };

      fetch('/api/endpoint', {
        method: 'POST',
        headers: {
          'Content-Type': 'application/json',
        },
        body: JSON.stringify(formData),
      })
        .then((response) => response.json())
        .then((data) => console.log('Success:', data))
        .catch((error) => console.error('Error:', error));
    });
</script>

With this kind of content type it is still not natively supported to upload files. It would mean you'd have to encode the file as a base64 string and send it as a string. This is not very efficient, and it is not the way to go if you want to upload large files.

`multipart/form-data`

HTML forms used to be used primarily for text data. But as the web became more interactive, it became necessary for HTML forms to support file uploads, too. In 1995, a Request For Comment (RFC) called RFC-1867 was published that proposed extending the functionality of HTML forms to start supporting file uploads. This is how we arrive at the multipart/form-data content type.

This content type has made it possible to deal with multiple types of data in one request (thus, the name multipart). It can handle text data but also binary data, which is necessary for file uploads. This makes this content type a native way to upload files. While previous content types could be tweaked to send files by converting files into a Base64 string, this is not necessary with multipart/form-data.

This is what it would look like to send the data from the form above to a server using multipart/form-data:

<script>
  document
    .getElementById('myForm')
    .addEventListener('submit', function (event) {
      event.preventDefault();

      var formData = new FormData(this);

      fetch('your-server-endpoint', {
        method: 'POST',
        body: formData,
      })
        .then((response) => response.json())
        .then((data) => console.log('Success:', data))
        .catch((error) => console.error('Error:', error));
    });
</script>

Diving into FormData

Now that we've arrived at the topic of FormData let's take a deep dive into it. There are two parts to FormData: the multipart/form-data content type and the FormData object. The multipart/form-data content type is a piece of metadata that is added to the request header so the server knows how to handle the data. Looking at the previous example, you can see that we're not actively adding this header to our fetch(). This is because if fetch detects that we're sending the FormData interface, it automatically adds that header for us.

The FormData interface is a JavaScript interface that makes it really easy to create a key/value pair that can be sent to a server.

Creating a FormData object

Because FormData is a JavaScript interface, we can create a new instance of it using new. There are three ways that we can instantiate a new FormData object:

// Without any arguments, creates an empty FormData object
const formData = new FormData();

// Pass in a form element to create a FormData object
const formData = new FormData(document.getElementById('myForm'));

// Passing in a form element together with the submit button from the form.
// If the button has a name attribute, it will be included in the FormData object.
const formData = new FormData(
  document.getElementById('myForm'),
  document.getElementById('submit-button')
);

Available methods on FormData

At the time of writing, FormData supports nine methods on its instance: append(), delete(), entries(), get(), getAll(), has(), keys(), set() and values().

// An empty form data object
const formData = new FormData();

// Using append() we can add a new key/value pair to the FormData object
formData.append('name', 'Jo');
formData.append('favorite-food', 'Pizza');

// Using delete() we can delete a key/value pair from the FormData object
formData.delete('name');
formData.append('name', 'Joan');

// Using entries() we can get an iterator that contains all the key/value pairs
for (const pair of formData.entries()) {
  console.log(`${pair[0]}, ${pair[1]}`);
}

// output:
// name, Joan
// favorite-food, Pizza

// Using get() we can get the value of a key
formData.get('name'); // returns 'Joan'

// Using getAll() we can get all the values of a key
formData.getAll('name'); // returns ['Joan']

// Using has() we can check if a key exists
formData.has('name'); // returns true

// Using keys() we can get an iterator that contains all the keys
for (const key of formData.keys()) {
  console.log(key);
}

// output:
// name
// favorite-food

// Using set() we can set the value of an existing key or create a new key/value pair if the key does not exist yet.
formData.set('name', 'Jo');

// Using values() we can get an iterator that contains all the values
for (const value of formData.values()) {
  console.log(value);
}

// output:
// Jo
// Pizza

Sending a FormData object to a server

In our previous example, this is how we sent the data from our HTML form to the server:

document.getElementById('myForm').addEventListener('submit', function (event) {
  event.preventDefault();

  var formData = new FormData(this);

  fetch('/api/endpoint', {
    method: 'POST',
    body: formData,
  })
    .then((response) => response.json())
    .then((data) => console.log('Success:', data))
    .catch((error) => console.error('Error:', error));
});

Walking through this:

We have added a submit event listener to the form element.
On the submit event, we prevent the default behavior of the form.
We create a new FormData object using this as an argument. Because we added an event listener to the form element in JavaScript, the function we provided as the event handler gets executed in the context of the element that the event was attached to. This means that this inside the function refers to that element.
We then send the FormData object to the server using fetch(). Because we're sending a FormData object, fetch() automatically adds the multipart/form-data content type to the request header.

Receiving FormData on the server

Without a file upload

Now that we've seen how we can send FormData to a server let's look at the simplest way possible to receive this on a node.js server. Node.js does not support parsing the multipart/form-data content type by default, which means that we need to add a little piece of middleware called multer.

Multer is middleware that you can use for handling multipart/form-data requests. Middleware is code that you can add to your server that runs between the request and the server's response, adding some automation to the process so you don't have to manually handle parsing the request. There are other pieces of middleware that could help with handling multipart/form-data requests, but for this example, we'll go with Multer.

Let's look at the simplest example with node.js, express and multer:

const express = require('express');
const multer = require('multer');
const app = express();

const upload = multer();

app.post('/api/endpoint', upload.none(), (req, res) => {
  const { body } = req;
  console.log({ body });
  res.send('Data received successfully');
});

const PORT = process.env.PORT || 3000;

app.listen(PORT, () => {
  console.log(`Server is running on port ${PORT}`);
});

The steps we took to write this code:

We imported express and multer.
We created an instance of express and assigned it to the variable app.
We created an instance of multer and assigned it to the variable upload.
We created a route for a POST request to the /api/endpoint path.
We used multer's none() method to tell multer that we're not expecting any files to be uploaded.
We added a callback function that will be executed when a request is made to the /api/endpoint path.
Inside the callback function we log the data that we received from the request.

With a file upload

Now, let's set up the logic to also upload a file using this form. We'll first need to add a file input to our form:

<form id="myForm" method="post" action="/" enctype="multipart/form-data">
  <label for="name">Name:</label>
  <input type="text" id="name" name="name" />

  <label for="favorite-food">Favorite food:</label>
  <input type="text" id="favorite-food" name="favorite-food" />

  <label for="file">File:</label>
  <input type="file" id="file" name="file" />

  <input type="submit" value="Submit" />
</form>

If we tried to send this to the current implementation of our server endpoint, it would give us the error MulterError: Unexpected field. This is because we are still using upload.none() in our middleware. We need to change this to upload.single('file') to tell multer that we're expecting a single file to be uploaded. Multer will add a file property to the req object that we can use to access the file that was uploaded. Let's log that file as well.

const express = require('express');
const multer = require('multer');
const app = express();

const upload = multer();

app.post('/api/endpoint', upload.single('file'), (req, res) => {
  const { body, file } = req;
  console.log({ body, file });
  res.send('Data received successfully');
});

const PORT = process.env.PORT || 3000;
app.listen(PORT, () => {
  console.log(`Server is running on port ${PORT}`);
});

With this setup, it should be possible to log both your body and the data of the file you've sent. Hopefully, this clarifies the usage and background of FormData. Happy coding!

What is the difference between HTTP versions?

Karin — Mon, 12 Feb 2024 09:00:00 +0000

You use it every day: HTTP. But have you ever taken a closer look at it? I got curious and decided to dive into it, specifically the differences between HTTP versions. This is what I found.

What is HTTP?

HTTP stands for HyperText Transfer Protocol and is used to transfer data over the web. When you type a URL in your browser - which from now on we'll call a 'client' - the client will send a request for a webpage to a server. This request is done using HTTP. This protocol is the language that both the client and the server use to communicate with each other.

Where is it used?

HTTP is the foundation for communicating on the World Wide Web. It makes it possible to do many things, like loading a webpage, sending an email, or posting on social media. This means HTTP is used everywhere. It is not only used in your browser but also on your phone, smartwatch, and smart TV; if you have a smart fridge, it'll be used there as well. Got a smart car? It's using HTTP. Are you smart? Then you're probably using it as well! Just kidding.

Either way, it's used in a lot of places. But did you know there are also different versions of the protocol? Let's find out what makes them different.

Why are there different versions?

Just as regular languages tend to evolve over time, so does HTTP. I will do as high-over a comparison as possible for my comparisons and only go into a little detail.

HTTP/0.9

The first version of HTTP (version 0.9) was released in 1991. It was pretty simple and only supported doing a GET request. This meant that you could get data but not send any data.

HTTP methods

A GET request defines what type of request the HTTP request is. GET is also referred to as an HTTP method. The GET method retrieves data from a server, which is used a lot on the World Wide Web. There are more HTTP methods, but we'll get to those later.

A request looked something like this:

GET /index.html

Headers

This version of HTTP did not allow for the use of headers. Headers are a way to send extra information to the server. For example, it can tell the server what kind of data you are sending or expecting to receive. Because HTTP/0.9 did not support headers, it was only possible to get an HTML page.

HTML

HTML stands for HyperText Markup Language. This language is used to create web pages. It describes the structure of a document.

HTTP/1.0

Version 1.0 of HTTP was released in 1996. It had quite a few improvements over the last version. It included more HTTP methods and supported adding headers, which made it possible to send more types of data.

A request looked something like this:

GET /index.html HTTP/1.0
Host: example.com

POST /index.html HTTP/1.0
Host: example.com
Content-Type: application/json

{
"name": "Jesse",
"age": 27
}

HTTP methods

The following HTTP methods were supported in version 1.0:

Headers

Allowing for headers made it possible to not only GET HTML pages but also other types of data. Combined with HTTP methods like POST, it also made it possible to send data to a server. For example, the combination of POST and a header like Content-Type: application/json together with a Content-Length header made it possible to send JSON data to a server.

Caching

With headers available, it became possible for servers to work together with the client to cache data. A server could let the client know how long it should store the data. In turn, the client could let the server know if it still had the data in its cache. This significantly improved how quick it was to browse the web.

Status codes

It's always possible that something might go wrong when you're sending an HTTP request. Maybe the server doesn't have the resource you're requesting of it, or perhaps you do not have the proper permissions to access it. In HTTP/0.9, there was no way for you to know if your request succeeded. With HTTP/1.0, this changed: it became possible to send a status code along with the response. It became possible to know if your request succeeded or not.

There were five different groups of status codes defined:

1xx: Informational
2xx: Success
3xx: Redirection
4xx: Client Error
5xx: Server Error

HTTP/1.1

It took only a short time after the release of HTTP/1.0 for HTTP/1.1 to be released. It was released in 1997, but the specification was updated many times after that. It is still the most used version of HTTP today. A bunch of information on this standard can be found in this document.

Persistent connections and lower latency

When using HTTP, you need to first make a connection to the server. Once the connection has been made, you can send your request. In HTTP/1.0, that connection was closed by default every time you made a request. This meant that if you wanted to ask one server for multiple resources, you had to start a new connection each time you wanted to do that. To make a connection, you need to do something called a 'handshake'. To do a handshake (and this is simplified), you ask the server if you can make a request; if it says yes, you can make your request. Doing this handshake takes time, and it meant that every GET request consisted of a handshake, approval for the handshake, and then the actual request. This took a lot of time and increased something we call 'latency', which is the time it takes for a request to be made and a response to be received.

Real life comparison:
This would have been the same as going to the bakery to buy a loaf of bread, a cake, and some white buns. You would ask the baker if you can do an order. They would say: yes, you can; what would you like? You would tell them: "I want a loaf of bread". They would get it for you, and you would pay, leave the store, and go through the entire process again to also get your cake and white buns. It would make more sense to say: "I'd like a loaf of bread, a cake, and some white buns," without having to leave the store in between.

Thankfully, in HTTP/1.1, the default behavior was to keep this connection open. This meant that you could make more than one request over the same connection. This made the web a lot faster.

Chunks

HTTP/1.1 also became cute and chonky, like a fluffed-up puppy or cat.

ahum

What I meant to say is that it became possible to send data with an unclear size. With previous versions of HTTP, you had to know how big the data that you were sending was. But it is only sometimes possible to know how big a file might be. So, 'chunked transfer encoding' was introduced. It was now possible to send chunks of data. Once all the data was sent, the server would let the client know that it was done sending data.

Host

Now, back in the day, one server would usually host one website. This meant that you first connected to the server, which was at one IP address, and then you would ask for a resource, like an HTML page. But as the World Wide Web grew, servers started hosting more websites. This meant that you'd also have to tell the server from which website you wanted to get your HTML page. This is where the Host header came in.

HTTP/2

In 2015, HTTP/2 was officially standardized and released by a team called the "Internet Engineering Task Force" (IETF). The goal of HTTP/2 was to support a growing web, including its increasing complexity. A big part of that was to improve performance.

Multiplexing

Remember those 'persistent connections'? Where you wouldn't have to create a new connection for each new request you wanted to make? Well, in HTTP/2, they took that a step further. They introduced something called 'multiplexing'. This meant that you could send multiple requests at the same time without having to wait for the response of the last request, kind of like asking both the baker and their coworker for different baked goods at the same time. This greatly improved performance.

Compressing headers

Headers are handy, but the more you use along with your request, the bigger it gets. With HTTP/2, it became possible to make headers smaller by compressing them.

Speaking binary

As mentioned before, HTTP is a protocol, and we can compare it to a language that both the client and the server know how to speak. But this language has always been human-readable, which is great for us but unnecessary for both the client and the server. These two already speak binary, so why not make HTTP speak binary as well? HTTP/2 introduced a binary protocol. This way, it was easier for the client and server to talk to each other.

Prioritization of requests

Some parts of a webpage are more important than others. For example, the HTML of a webpage is more important than the images on it. Or any critical CSS is more important than the CSS that styles the page. This is why HTTP/2 introduced the ability to prioritize requests. The client can now let the server know which resources are more important than others.

Security

While it is possible to use the security protocol TLS/SSL with HTTP/1.1, you do not have to. The team working on HTTP/2 HIGHLY recommends using it, helping to make the web more secure.

Pushing resources

HTTP/2 made it possible for a server to actually take the initiative and push resources to the client without the client actually asking for it. This is called 'server push'. It can be used to send resources that the client will need in the future without it knowing it needs them.

HTTP/3

The latest version HTTP/3 was published as a proposal in 2022. The big difference between HTTP/3 and HTTP/2 (and, thereby, HTTP1.1) is that the way that the client connects to the server is changed. This should lead to a faster web experience.

Transport protocol

HTTP has always used something called the Transmission Control Protocol (TCP) as its way to connect to a server. However, in HTTP/3, they introduced a different type of protocol called QUIC. This is a protocol that is built on top of UDP, which is a protocol that is similar to TCP, but it doesn't have to do a handshake before it can send data. This makes it faster to connect with.

QUIC should make things like the earlier mentioned multiplexing and prioritization of requests even faster. It is also supposed to handle any errors if something goes wrong during a request.

Security

While HTTP/2 does encourage the use of the security protocol called HTTPS, it does not require it. QUIC is built on top of UDP, which, by default, is not secure. This is why HTTP/3 generally requires using the HTTPS security protocol. QUIC does mention that it has built-in security features, but it is still recommended to use HTTPS.

Conclusion

Yes. This was a lot of information, of which I'm sure I've not mentioned or found some details that could be super important, but oh well. I did not know HTTP could be this interesting. It surprised me just as much as the time I started diving into hashing. I hope you learned something new as well! Have fun coding!

Integrate PlanetScale in your Next.js site and authenticate using Netlify Identity

Karin — Tue, 16 Jan 2024 17:00:00 +0000

Thanks to services like PlanetScale, creating a MySQL database for your site is easier than ever! And by adding Netlify Identity you get to protect your site with authentication as well. In this tutorial we’ll guide you through setting up PlanetScale through our amazing integration and how to implement Netlify Identity as well. The finished result will be a very simple site using Next.js, PlanetScale, Netlify Identity and Netlify Functions where a user can sign up, log in and where we can get, post and delete data from our database.

TL;DR

The finished result will be a very simple site using Next.js, PlanetScale, Netlify Identity and Netlify Functions where a user can sign up, log in and where we can get, post and delete data from our database. For a quick talk through some of the details, you can dip in to this short video.

Or if you want to dive right in to explore the repository and deploy a demo, click the deploy To Netlify button below (After you’ve clicked that button, make sure to follow the steps to enable PlanetScale and Netlify Identity down below, and it should work!).

Prerequisites

These are the things you’ll need to set up before starting this tutorial:

Getting our site ready

Done exploring the example site and ready to explore and understand the steps to build this? Let’s go! Let's create a basic Next.js site and deploy it to Netlify, in your terminal run:

npx create-next-app

Follow the default options, we decided to use the src directory. Then, let's deploy it to Netlify. Make sure to have the Netlify CLI installed and to log in using the command netlify login. Then, run cd my-next-app and commit and push your repository to a service like GitHub. After this run netlify init and follow the prompts. When you're done, run netlify open to open your site's settings in your Netlify account.

Enable PlanetScale

The database in your PlanetScale account should have the following table:

CREATE TABLE `issues` (
  `id` int NOT NULL AUTO_INCREMENT,
  `title` varchar(255) NOT NULL,
  `assignee_name` varchar(255) NOT NULL,
  `assignee_email` varchar(255),
  `status` enum('to-do', 'in progress', 'done') DEFAULT 'to-do',
  PRIMARY KEY (`id`)
);

Netlify integrations provide a convenient way to authenticate with third-party tools and services so that developers in your organisation can easily make use of them.

In your Netlify site view, navigate to Integrations and under the Database category enable PlanetScale. On the next page, click 'connect'. You'll be redirected to PlanetScale where you can authorise Netlify to access your database. Once you've done that, you'll be redirected back to Netlify and you can select your organisation, database and configure which PlanetScale branch should be used in what environments for your Netlify site.

Enable Netlify Identity

The composable architecture we’re using here affords us the option to use a variety of different Identity providers, but for this example we’ll use Netlify Identity. In your Netlify Site Configuration, go to the Identity tab and enable Identity. You won't be using any external providers for this example so you don’t need to configure those.

Configuring your Next.js app

Now that we’ve set up PlanetScale and Netlify Identity, we’re ready to install some of our dependencies:

npm install netlify-identity-widget @types/netlify-identity-widget @netlify/functions @netlify/planetscale

Configure Netlify Identity

We'll be using React Context to make the Netlify Identity instance available to all components in our app. Create a new file src/context/authContext.tsx and add the following contents:

// src/context/authContext.tsx
import netlifyIdentity, { type User } from "netlify-identity-widget";
import { createContext, useEffect, useState } from "react";

declare global {
  interface Window {
    netlifyIdentity: any;
  }
}

interface NetlifyAuth {
  isAuthenticated: boolean;
  user: User | null;
  initialize(callback: (user: User | null) => void): void;
  authenticate(callback: (user: User) => void): void;
  signout(callback: () => void): void;
}

const netlifyAuth: NetlifyAuth = {
  isAuthenticated: false,
  user: null,
  initialize(callback) {
    window.netlifyIdentity = netlifyIdentity;
    netlifyIdentity.on("init", (user: User | null) => {
      callback(user);
    });
    netlifyIdentity.init();
  },
  authenticate(callback) {
    this.isAuthenticated = true;
    netlifyIdentity.open();
    netlifyIdentity.on("login", (user) => {
      this.user = user;
      callback(user);
      netlifyIdentity.close();
    });
  },
  signout(callback) {
    this.isAuthenticated = false;
    netlifyIdentity.logout();
    netlifyIdentity.on("logout", () => {
      this.user = null;
      callback();
    });
  },
};

This will create a netlifyAuth object that we can use to interact with Netlify Identity. Now let's create AuthContext and implement the netlifyAuth object.

// src/context/authContext.tsx
interface AuthContextType {
  user: User | null;
  login: () => void;
  logout: () => void;
  loading: boolean;
  deleteAccount?: () => void;
}
export const AuthContext = createContext<AuthContextType>({
  user: null,
  login: () => {},
  logout: () => {},
  loading: false,
  deleteAccount: () => {},
});

And now we'll create the provider:

// src/context/authContext.tsx
export const AuthContextProvider = ({ children }: { children: React.ReactNode }) => {
  const [loggedIn, setLoggedIn] = useState<boolean>(netlifyAuth.isAuthenticated);
  const [user, setUser] = useState<User | null>(null);
  const [loading, setLoading] = useState<boolean>(true);

  const login = () => {
    netlifyAuth.authenticate((user) => {
      setLoggedIn(!!user);
      setUser(user);
    });
  };

  const logout = () => {
    netlifyAuth.signout(() => {
      setLoggedIn(false);
      setUser(null);
    });
  };

  const deleteAccount = () => {
    // TODO
  };

  useEffect(() => {
    netlifyAuth.initialize((user: User | null) => {
      setUser(user);
      setLoggedIn(!!user);
    });
    setLoading(false);
  }, [loggedIn]);

  const contextValues = { user, login, logout, loading, deleteAccount };

  return <AuthContext.Provider value={contextValues}>{children}</AuthContext.Provider>;
};

We’ll now be navigating to your app's layout file, in our case it is located at src/app/layout.tsx, we'll wrap the app in the AuthContextProvider:

// src/app/layout.tsx
"use client";

import { AuthContextProvider } from "@/context/authContext";

export default function Layout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        <AuthContextProvider>{children}</AuthContextProvider>
      </body>
    </html>
  );
}

From now on, all children of the AuthContextProvider will have access to the AuthContext we created earlier. This means we'll be able to use the different functions from the AuthContext to add login and logout buttons to our app.

// src/app/page.tsx
"use client";

import { AuthContext } from "@/context/authContext";
import { User } from "netlify-identity-widget";
import { useContext, useEffect, useState } from "react";

export default function Home() {
  const { user, login, logout, loading } = useContext(AuthContext);

  if (loading) return <div>Loading...</div>;

  return user ? (
    <>
      <button onClick={logout}>Log out</button>
    </>
  ) : (
    <button onClick={login}>Log in / Register</button>
  );
}

Time to try it out! Commit your work and push it.

The site will automatically be redeployed on Netlify. You can jump straight to the deployed site to try it out with netlify open --site but to assist with troubleshooting during development you can also run it locally, complete with access to the integrations with netlify dev. You should be able to log in and log out of the example app now! The first time you register it will send you through the production registration flow. This means that locally you'll have to log in with the credentials you set up on production to see your logged in state. You can also check the Netlify Identity tab in your Netlify Site Configuration view to see the users that have been created.

Adding a form to create database entries

Now that we have Netlify Identity set up, let's add a form to create issues in our PlanetScale database. Add the following code to src/app/page.tsx:

// src/app/page.tsx
"use client";

import { AuthContext } from "@/context/authContext";
import { User } from "netlify-identity-widget";
import { useContext, useEffect, useState } from "react";

export default function Home() {
  const { user, login, logout, loading } = useContext(AuthContext);
  const [issueTitle, setIssueTitle] = useState("");

  const handleInputChange = (event: React.ChangeEvent<HTMLInputElement>) => {
    setIssueTitle(event.target.value);
  };

  const handleSubmit: React.FormEventHandler<HTMLFormElement> = async (event) => {
    event.preventDefault();
    try {
      await fetch(`/.netlify/functions/create`, {
        method: "POST",
        headers: {
          // this will ensure that the Netlify function has access to the user object.
          Authorization: `Bearer ${user?.token?.access_token}`,
        },
        body: JSON.stringify({
          title: issueTitle,
        }),
      });
    } catch (error) {
      console.error("Error submitting issue:", error);
    }
  };

  if (loading) return <div>Loading...</div>;

  return user ? (
    <>
      {/* Our new form */}
      <form onSubmit={handleSubmit}>
        <label htmlFor="title">Title:</label>
        <input
          onChange={handleInputChange}
          type="text"
          id="title"
          name="title"
          placeholder="Add an issue"
          required
          value={issueTitle}
        />

        <button type="submit">Submit</button>
      </form>
      <button onClick={logout}>Log out</button>
    </>
  ) : (
    <button onClick={login}>Log in / Register</button>
  );
}

We need something to handle and process the POST submissions from our form. Netlify Functions are an ideal way to do this without adding the dependency of a server. We’re actually going to add a number of APIs using serverless functions to support the functionality of our app as we progress.

Let’s start with handling the form submissions and creating a new issue in our database. Create a new file netlify/functions/create.ts and add the following code:

// netlify/functions/create.ts
import connection from "@netlify/planetscale";
import type { Handler, HandlerEvent, HandlerContext } from "@netlify/functions";

const handler: Handler = async function (event: HandlerEvent, context: HandlerContext) {
  // We get the user from the context's clientContext
  const { user } = context.clientContext as {
    identity: { url: string; token: string };
    user: { sub: string; email: string; user_metadata: { full_name: string } };
  };

  if (!event.body) {
    return {
      statusCode: 400,
      body: "Please provide a title for the issue",
    };
  }
  // This checks wether the user is logged in or not
  if (!user?.sub || !user?.email) {
    return {
      statusCode: 401,
      body: "Unauthorized",
    };
  }

  const body = JSON.parse(event.body);

  // We insert the issue into the PlanetScale database using the user's name and email from the user object
  return connection
    .execute(
      `
    INSERT INTO issues (title, assignee_name, assignee_email)
    VALUES (?, ?, ?)
    `,
      [body.title, user.user_metadata.full_name, user.email]
    )
    .then(() => {
      return {
        statusCode: 200,
        body: JSON.stringify({ message: "Issue created" }),
      };
    })
    .catch((error) => {
      return {
        statusCode: 500,
        body: `Internal Server Error: ${error}`,
      };
    });
};

export { handler };

It should now be possible to create issues in your PlanetScale database! Try adding one and then checking your PlanetScale database to see if it worked.

Showing a list of entries from your database

Now that we can create issues, let's add a list of issues to our app. We'll create a new serverless function to get all issues from our PlanetScale database. Create a new file netlify/functions/get.ts and add the following code:

// netlify/functions/get.ts
import type { Handler, HandlerEvent, HandlerContext } from "@netlify/functions";
import connection from "@netlify/planetscale";

const handler: Handler = async function (_event: HandlerEvent, context: HandlerContext) {
  // We get the user from the context's clientContext
  const { user } = context.clientContext as {
    identity: { url: string; token: string };
    user: { sub: string; email: string };
  };

  // This checks wether the user is logged in or not
  if (!user?.sub || !user?.email) {
    return {
      statusCode: 401,
      body: "Unauthorized",
    };
  }

  // We get all issues from the PlanetScale database
  return await connection
    .execute(`SELECT * FROM issues`)
    .then((issues) => {
      const { rows } = issues;

      return {
        statusCode: 200,
        body: JSON.stringify(rows),
      };
    })
    .catch((error) => {
      return {
        statusCode: 500,
        body: `Internal Server Error: ${error}`,
      };
    });
};

export { handler };

Now inside of src/app/page.tsx we'll add a new useEffect hook to fetch the issues from our PlanetScale database. We'll also add a new state variable to store the issues in. After a new issue is submitted we'll also fetch the issues again to update the page. The code will look like this:

// src/app/page.tsx
"use client";

import { AuthContext } from "@/context/authContext";
import { User } from "netlify-identity-widget";
import { useContext, useEffect, useState } from "react";

interface Issue {
  id: string;
  title: string;
}

const fetchIssues = async (user: User) => {
  const res = await fetch("/.netlify/functions/get", {
    headers: {
      Authorization: `Bearer ${user?.token?.access_token}`,
    },
  });
  const data = await res.json();
  return data;
};

export default function Home() {
  const { user, login, logout, loading } = useContext(AuthContext);
  const [issues, setIssues] = useState<Issue[]>([]);
  const [loadingIssues, setLoadingIssues] = useState<boolean>(true);
  const [issueTitle, setIssueTitle] = useState("");

  useEffect(() => {
    if (user) {
      fetchIssues(user).then((issues) => {
        setIssues(issues);
        setLoadingIssues(false);
      });
    }
  }, [user]);

  const handleInputChange = (event: React.ChangeEvent<HTMLInputElement>) => {
    setIssueTitle(event.target.value);
  };

  const handleSubmit: React.FormEventHandler<HTMLFormElement> = async (event) => {
    event.preventDefault();
    try {
      await fetch(`/.netlify/functions/create`, {
        method: "POST",
        headers: {
          // this will ensure that the Netlify function has access to the user object.
          Authorization: `Bearer ${user?.token?.access_token}`,
        },
        body: JSON.stringify({
          title: issueTitle,
        }),
      });

      if (user) {
        fetchIssues(user).then((issues) => {
          setIssues(issues);
        });
      }
    } catch (error) {
      console.error("Error submitting issue:", error);
    }
  };

  if (loading || loadingIssues) return <div>Loading...</div>;

  return user ? (
    <>
      {/* Our new form */}
      <form onSubmit={handleSubmit}>
        <label htmlFor="title">Title:</label>
        <input
          onChange={handleInputChange}
          type="text"
          id="title"
          name="title"
          placeholder="Add an issue"
          required
          value={issueTitle}
        />

        <button type="submit">Submit</button>
      </form>
      {/* List our issues */}
      <ul>
        {issues.map((issue) => (
          <li key={issue.id}>{issue.title}</li>
        ))}
      </ul>
      <button onClick={logout}>Log out</button>
    </>
  ) : (
    <button onClick={login}>Log in / Register</button>
  );
}

Delete users from Netlify Identity and their entries from PlanetScale

We want to make sure that users can also delete their account and issues. Let's make a new serverless function in netlify/functions/delete.ts. In that file we'll check if the user is currently logged in and authenticated, and then we delete that user Netlify Identity, and delete all of their entries from our PlanetScale database. The code will look like this:

// netlify/functions/delete.ts
import type { Handler, HandlerEvent, HandlerContext } from "@netlify/functions";
import connection from "@netlify/planetscale";

const handler: Handler = async function (_event: HandlerEvent, context: HandlerContext) {
  const { identity, user } = context.clientContext as {
    identity: { url: string; token: string };
    user: { sub: string; email: string };
  };

  if (!user?.sub || !user?.email) {
    return {
      statusCode: 401,
      body: "Unauthorized",
    };
  }

  const userUrl = `${identity.url}/admin/users/{${user.sub}}`;
  const adminAuthHeader = `Bearer ${identity.token}`;

  return fetch(userUrl, {
    method: "DELETE",
    headers: { Authorization: adminAuthHeader },
  })
    .then(async () => {
      console.log("Deleted a user!");

      await connection.execute(
        `
          DELETE FROM issues
          WHERE assignee_email = ?
          `,
        [user.email]
      );
    })
    .then(() => {
      console.log("Deleted all issues assigned to the user!");
      return { statusCode: 204 };
    })
    .catch((error) => ({
      statusCode: 500,
      body: `Internal Server Error: ${error}`,
    }));
};

export { handler };

Inside the deleteAccount function in the authContext file, we'll do a call to the function we just created. We'll first ask the user to confirm they want to delete their account, and then we'll call the serverless function. The code will look like this:

// src/context/authContext.tsx
const deleteAccount = () => {
  if (window.confirm("Are you sure? This will delete the issues you created and your account. ")) {
    fetch("/.netlify/functions/delete", {
      method: "DELETE",
      headers: {
        Authorization: `Bearer ${user?.token?.access_token}`,
      },
    })
      .then(async () => logout())
      .catch((err) => console.error(err));
  }
};

This function is exported in the AuthContext provider, so you can use it in any children of the AuthContextProvider. For example by providing a button that calls the function.

// src/app/page.tsx
"use client";

import { AuthContext } from "@/context/authContext";
import { User } from "netlify-identity-widget";
import { useContext, useEffect, useState } from "react";

interface Issue {
  id: string;
  title: string;
}

const fetchIssues = async (user: User) => {
  const res = await fetch("/.netlify/functions/get", {
    headers: {
      Authorization: `Bearer ${user?.token?.access_token}`,
    },
  });
  const data = await res.json();
  return data;
};

export default function Home() {
  const { user, login, logout, loading, deleteAccount } = useContext(AuthContext);
  const [issues, setIssues] = useState<Issue[]>([]); // Provide type for issues state variable
  const [loadingIssues, setLoadingIssues] = useState<boolean>(true);
  const [issueTitle, setIssueTitle] = useState("");

  useEffect(() => {
    if (user) {
      fetchIssues(user).then((issues) => {
        setIssues(issues);
        setLoadingIssues(false);
      });
    }
  }, [user]);

  const handleInputChange = (event: React.ChangeEvent<HTMLInputElement>) => {
    setIssueTitle(event.target.value);
  };

  const handleSubmit: React.FormEventHandler<HTMLFormElement> = async (event) => {
    event.preventDefault();
    try {
      await fetch(`/.netlify/functions/create`, {
        method: "POST",
        headers: {
          // this will ensure that the Netlify function has access to the user object.
          Authorization: `Bearer ${user?.token?.access_token}`,
        },
        body: JSON.stringify({
          title: issueTitle,
        }),
      });
    } catch (error) {
      console.error("Error submitting issue:", error);
    }
  };

  if (loading || loadingIssues) return <div>Loading...</div>;

  return user ? (
    <>
      {/* Our new form */}
      <form onSubmit={handleSubmit}>
        <label htmlFor="title">Title:</label>
        <input
          onChange={handleInputChange}
          type="text"
          id="title"
          name="title"
          placeholder="Add an issue"
          required
          value={issueTitle}
        />

        <button type="submit">Submit</button>
      </form>
      {/* List our issues */}
      <ul>
        {issues.map((issue) => (
          <li key={issue.id}>{issue.title}</li>
        ))}
      </ul>
      <button onClick={logout}>Log out</button>
      <button onClick={deleteAccount}>Delete account</button>
    </>
  ) : (
    <button onClick={login}>Log in / Register</button>
  );
}

The full example

If you want to see the full code of our example, check out the repository here. If you want to deploy the example site to your Netlify account, feel free to click the Deploy to Netlify button down below

After you’ve clicked that button, make sure to follow the steps to enable PlanetScale and Netlify Identity in this article.

What's next?

Congrats! You now have a working example and you are ready to start building your own app! You’ve learned how to use the PlanetScale integration on Netlify and how to implement Netlify Identity. If you want to try out more, here are some ideas:

Add a form to update issues
Add a button to delete issues
Make it possible to change the status of an issue

Resources

Build your own integrations with Netlify: check out the Netlify SDK!
The PlanetScale integration
Learn more about Netlify Serverless Functions
Learn more about Netlify Identity
Next.js

Share your Netlify integration with the click of a button

Karin — Wed, 15 Nov 2023 14:51:59 +0000

Have you just created an amazing integration for Netlify? Then why not share it with the community! It’s as easy as using our Deploy to Netlify button and linking to your integration template. Let me show you how!

Netlify Integrations

Netlify Integrations extend the capabilities of the Netlify platform and enable you to streamline developer workflows. By using the Netlify SDK you can add custom data sources for Netlify Connect, create sitemaps, RSS feeds, or search indexes as part of the build process. You can also do things like check for broken links in a site after the build completes but before the site is deployed, monitor serverless function activity with an integration wrapper or simplify the workflow for developers using your service with Netlify by doing things like generating required environment variables automatically instead of asking users to set them manually.

Create your integration

First, make sure to create your integration using the Netlify SDK. Once it’s ready to be tested, try it out by creating a private integration on your Netlify account. I bet it is amazing! So let’s make sure to share it with the rest of the web community so they can benefit from it as well.

Make a public repository with a readme

Ensure that your integration is committed to a public repository on GitHub. This will allow people to use your code and deploy the integration as a private integration on their Netlify account.

In this repository you can add a README.md file. This can contain information on what the integration does, but maybe just as important: this is where we’ll add the Deploy to Netlify button so people can actually try it out on their own account as well.

Add the Deploy to Netlify button

In your README.md add the following code, replacing repository_url with the url to your public GitHub repository.

[![Deploy to Netlify](https://www.netlify.com/img/deploy/button.svg)](https://app.netlify.com/integration/start/deploy?repository=repository_url)

If you commit this to your repository, people will now see a button in your README.md that will allow them to deploy and try out your integration by simply clicking it. It will lead them through a few small steps and within no time it is deployed to their Netlify team as a private integration.

Curious what this might look like? Try the button below!

Extra configuration

It’s also possible to add additional configuration to your button. For example: you can pre-populate some fields that the person clicking the button would otherwise have to fill in themselves. To learn more about this, check out the documentation!

Hook into Netlify’s build events with Private Integrations

Karin — Thu, 02 Nov 2023 16:18:00 +0000

Have you slowly seen your team’s build process grow into a complex monster with configuration files the size of Mount Doom? Don’t worry, we're here to help! Netlify Build Event Handlers can help make these processes more accessible for you and your team. Setting it up is a breeze — create a Private Integration once, and enable it for any site within your team. Did I mention it uses TypeScript? Throw out unnecessary complexity and join me in building next-generation integrations on Netlify.

What is a Build Event Handler?

Build Event Handlers open up a world of possibility by seamlessly integrating into the Netlify site building process and enhancing what Netlify builds can achieve. You can do things like perform post-build checks for broken links on your site, generate content such as sitemaps, RSS feeds, search indexes, and so much more. The imaginative digital sky is the limit!

As an example, I’m going to show you how you can build a private integration that checks for broken links on a site after building it but before deploying it. If it finds a broken link, it will automatically cancel the deploy.

Creating the basis for your private integration

You'll be using the Netlify SDK to create your private integration. In your terminal, navigate to the folder where you want to make your integration and type: pnpm create @netlify/sdk@latest.

You will be prompted with some questions that help guide you in creating your new integration. Feel free to choose your own package manager, but make sure to go with the following answers:

? Where do you want to create the integration? link-checker-integration
? What is the slug of the integration? (e.g. my-integration) link-checker-integration
? What level will this integration be installed on? site
? Summarize what your integration does. This will be shown on the integration's card
on the Integrations page. This integration checks your build for any broken links
? Which boilerplate should be included? build
? Which package manager do you want to use? pnpm
? Select your permission scopes site:read
? Do you want to link a Netlify site to your integration? This will help you test your integration and will be used to host your integration. skip

Then, you can navigate to the directory it created for you by typing cd link-checker-integration. If you run ls you should be seeing something similar to this:

├── integration.yaml
├── netlify.toml
├── package.json
├── pnpm-lock.yaml
├── src
│   └── index.ts
└── tsconfig.json

Your Build Event Handler boilerplate

The SDK already made a few files for you! Let’s open up src/index.ts to see what your Build Event Handler boilerplate looks like:

// Documentation: https://sdk.netlify.com
import { NetlifyIntegration } from "@netlify/sdk";

const integration = new NetlifyIntegration();

integration.onEnable(async (_, { teamId, siteId, client }) => {
  // Build event handlers are disabled by default, so we need to
  // enable them when the integration is enabled.

  siteId && await client.enableBuildEventHandlers(siteId);

  return {
    statusCode: 200,
  };
});

integration.addBuildEventHandler("onPreBuild", () => {
  console.log("Hello there.");
});

export { integration };

There are a number of events in the build pipeline you can hook into if you want. But for this example let’s change the onPreBuild function to onPostBuild. Then make the function async and grab some function parameters like constants and utils. Your addBuildEventHandler method should look something like this:

integration.addBuildEventHandler('onPostBuild', async ({ constants, utils }) => {
  console.log("Hello there.");
});

Adding linkinator

To add the functionality of scanning a site’s build folder for any broken links we will use a package called linkinator, go ahead and run pnpm install linkinator.

Make sure to import the LinkChecker class from the package and create a new instance of it. Then use constants.PUBLISH_DIR to pass the folder that should be checked for any broken links. In this case I assume it will be the PUBLISH_DIR. You can set up your Build Event Handler in a way that, if the package finds any broken links, the deploy is cancelled! This is done by leveraging utils.build.failBuild.

This is what the code should look like:

// Documentation: https://sdk.netlify.com
import { NetlifyIntegration } from '@netlify/sdk';
import { LinkChecker } from 'linkinator';

const integration = new NetlifyIntegration();

integration.onEnable(async (_, { teamId, siteId, client }) => {
  // Build event handlers are disabled by default, so we need to
  // enable them when the integration is enabled.

  siteId && (await client.enableBuildEventHandlers(siteId));

  return {
    statusCode: 200,
  };
});

integration.addBuildEventHandler(
  'onPostBuild',
  async ({ constants, utils }) => {
    const checker = new LinkChecker();
    // Pass the PUBLISH_DIR that the site was built in
    const result = await checker.check({
      path: constants.PUBLISH_DIR,
    });

    // Log wether we passed or failed!
    console.log(result.passed ? 'PASSED :D' : 'FAILED :(');

    if (!result.passed) {
      // The list of checked links, and the pass/fail
      const brokeLinksCount = result.links.filter(
        (x: { state: string }) => x.state === 'BROKEN'
      );
      console.log(`Detected ${brokeLinksCount.length} broken links.`);

      // Show the list of scanned links and their results
      console.log(result);
      // Fail the build and cancel the deploy if there are broken links
      utils.build.failBuild('There are broken links, fix them first!');
    }
  }
);

export { integration };

That’s it! You are now ready to deploy your integration.

Deploy your integration

Alright, let’s get your integration out there for your team to use! First, make sure you commit the latest changes to your repository and publish it to your Git provider, for example GitHub. This way we can leverage Netlify’s continuous deployment. When you’re done with that, use the Netlify CLI to run netlify init in your terminal and answer the questions:

? What would you like to do? Create & configure a new site
? Team: {your team name}
? Site name (leave blank for a random name; you can change it later): {keep blank}
? Your build command (hugo build/yarn run build/etc): netlify-integration build -a
? Directory to deploy (blank for current dir): .ntli/site/static

Alright, you're done! In your terminal, you should see an Admin URL. If you click it, it will take you to your admin panel in Netlify.

Creating a Private Integration

Now that we’ve deployed your code, we’re going to officially create a Private Integration out of it! In the Netlify UI, navigate to "integrations". Once you’re there, select "Create a private integration" and fill in the form. You can find detailed information on the fields you see here, but I’ll highlight a few special ones as well:

Netlify integration site: select the name of the integration you have just deployed in the previous step!
Integration level: this integration will only work on a site level, so choose site.
Permission scopes: we only need site "read" permissions for this integration.

Smash that "create" button! You're done!

Enabling your integration for your team’s sites

Now that your private integration has been deployed, we’re going to use it on one of your sites! Either find a site in your Netlify team that you want to use, or use the one I’ve made for you so you can test this integration out as soon as possible! You can deploy it with this button:

Once you’ve found a site you want to try your integration on, navigate to that site in the Netlify UI, and then go to "integrations". Once you’re there, select the private integrations category. In that list you should be able to see a card with the name of the integration you just created. Enable that integration by selecting the "enable" button.

If you now run a new deploy on the site you’ve enabled your integration on, you should be able to see logs from your integration in the ‘build’ section of your deploy logs! Congratulations, you did it!

Next steps and making your integrations public

If you just want to try out this integration, use the button below to deploy it to your Netlify Team. And don't forget to check out the template repository.

You can use this new integration on all of the sites you have within your Netlify Team! Learn more about building integrations on Netlify, or how to create a partner integration on Netlify.

Happy coding on Netlify!

Astro: a friendly and powerful companion for your content-driven site

Karin — Tue, 22 Aug 2023 00:00:00 +0000

When it comes to web development, there's always a new tool or framework around the corner. Yet, when I first stumbled upon Astro in the beginning of 2022 I thought, "Why not give it a go?". It was still super fresh and hadn't even reached v1 but I decided to test it out on my personal site.

The truth is, trying out new APIs or tools can be intimidating, especially when you're unsure of the challenges that might pop up. But, to my surprise, diving into Astro was different. The community was very active, and tools were being developed at a pace I hadn't expected for such a new framework. The level of clarity in their docs, the interactions on GitHub issues, and the vibrant chatter on their Discord was a breath of fresh air. But what really caught my attention? The total lack of gatekeeping.

It also felt like there was a really well-thought-through awareness of the different things the framework would not offer for the time being. It seemed like the people behind this project knew exactly why someone might want to try it out, and what they may run into when it came to possible problems.

Trimming your codebase

Setting up my personal blog using Astro felt quite easy. I was migrating from nextjs and was glad to get rid of every piece of unnecessary code. With its clean and straightforward APIs, I found myself really enjoying the simple codebase. And when it comes to performance? Astro is unmatched. The built-in features amplify efficiency, allowing you to focus on building rather than optimizing.

In essence, Astro is a delightfully lightweight and truly friendly web framework. Its charm is in its versatility, with an added bonus for markdown lovers. And while it supports most UI components, it also provides its own simple-to-use API. It strips away the unnecessary, letting your project shine, and the markdown support paired with the "island architecture" is a game-changer.

UI Components

For those familiar with React-heavy tools, Astro can feel like coming home. The option to use React, or any of the other popular UI Frameworks inside Astro is invaluable. But what Astro does even better is offering simplicity when needed. This shows especially in Astro's own component syntax which feels like a light-weight version of JSX. While I started off using React components, I've since migrated to Astro's own component syntax. It's simple to use and feels like a natural extension of HTML with the added bonus of being able to pass props.

However, what truly sets Astro apart, in my experience, is the community. It's one thing to have a brilliant tool, but when that's backed by a supportive and collaborative community it allows for a strong future. From Discord interactions to collaborative guidelines, you can really feel the respect and friendliness that Astro's community embodies.

So, when would I recommend Astro? If you're crafting a content-centric, swift website and looking for a web framework, Astro is your go-to. With its friendly community and innovative approach, any upcoming releases are looking very promising.

In my eyes, the future of web development should lean towards what Astro embodies: keeping complexities optional and championing communities rooted in collaboration.

Set up a Twitch chat bot using Websockets and Node.js

Karin — Sat, 15 Apr 2023 00:00:00 +0000

I really enjoy watching some twitch streamers, and because I am always delighted by the possibilities of API's and the fun that chatbots bring, I wanted to try writing a small chatbot that says hi. In this post I'll quickly bring you along in creating a quick and small prototype.

Prepare your Twitch account

If you haven't done so yet, make sure to create a Twitch account by going to twitch.tv and signing up. After you've created your account, note down your username. Then go to the Twitch Developer Console and login using your new Twitch account.

After this, click on "Register Your Application". Fill in the form by providing a name, adding the url http://localhost:3000 to OAuth Redirect URLs. You can choose Chatbot for the Category. Prove that you're not a robot (we're just making one). Then click "Create". After this, you'll see an overview of your applications. Click on "Manage" for the application you just registered. This is where you'll see something called your Client ID.

Prepare your code

Create a directory on your computer with the name of your chatbot, move into this folder and initialize git and npm. You can do this by doing the following inside your terminal:

// create a new directory
// just choose whatever name you want for your bot
$ mkdir twitch-bot

// move into your newly created directory
$ cd twitch-bot

// initialize a git repository
$ git init

// initialize your node project
$ npm init -y

Create a file called index.js which will be the main entrypoint for your code by typing touch index.js in your terminal.

Let's also go into our package.json and add an option called "type": "module" in the main object. Setting this type field to "module" will make sure that any file ending with .js is loaded as an ES Module.

I'm solely doing this because I like using the import statement when I import dependencies. Of which I only have one for this example. Yes, what an overengineered delight.

Adding our first dependency

Because we'll be working with websockets, and node does not support them by default, we're going to be installing the dependency called ws. You can also use tmi.js to interact with Twitch, but I decided to only use websockets when trying this out. In your terminal type:

npm i ws

Now open up index.js and import your newly installed package:

// index.js
import WebSocket from 'ws';

Getting an access token

Because our chatbot will need an access token, let's make sure we have one. We'll be taking some advice from the Twitch docs:

Open a browser and enter the following URL in the address bar:
https://id.twitch.tv/oauth2/authorize?response_type=token&client_id=<your client id>&redirect_uri=http://localhost:3000&scope=chat%3Aread+chat%3Aedit.
Replace "your client id" with the client ID you received when registering your bot. Replace the URL in the redirect_uri query parameter with the redirect URI you specified when registering your bot.
Enter your Twitch credentials if asked, and then authorize the scopes.
Get the access token from the address bar (see the access_token parameter in the fragment portion of the URI).

Now that you have your access token, let's add it to our index.js file:

// index.js
import WebSocket from 'ws';

const TOKEN = 'your token here';

Creating the websocket client and listening for events

Now let's make sure we create our websocket client. To do this we'll add the following to our index.js file:

const ws = new WebSocket('wss://irc-ws.chat.twitch.tv:443');

This is where we'll finally start interacting with Twitch's Internet Relay Chat (IRC) interface. This IRC allows us to send and receive messages to a Twitch Chat. If you want to know more, there is always the Twitch Documentation.

Now that we've created our websocket client, we'll start listening to some events. We'll listen to error, open, message and close. I'll set up close and error mostly for the purpose of being complete. The real interesting part will happen in message and open. This is how this will look in your file:

// index.js
import WebSocket from 'ws';

const TOKEN = 'your token here';
const ws = new WebSocket('wss://irc-ws.chat.twitch.tv:443');


ws.on('error', () => console.error());

ws.on('open', () => {
  console.log('Opened connection');
});

ws.on('message', (data) => {
  console.log('received: %s', data);
});

ws.on('close', () => console.log('Closed connection'));

With this logic set up, we're all ready to start setting up the logic of actually connecting to Twitch's IRC.

Connecting to the Twitch IRC

We now want to start connecting to the Twitch IRC. To do this we'll first ask access to Twitch by sending the message CAP REQ :twitch.tv/membership twitch.tv/tags twitch.tv/commands. Then we send our token using PASS and our username using NICK. This is done the following way:

// index.js
import WebSocket from 'ws';

const TOKEN = 'your token here';
const ws = new WebSocket('wss://irc-ws.chat.twitch.tv:443');


ws.on('error', () => console.error());

ws.on('open', () => {
  console.log('Opened connection');

  ws.send('CAP REQ :twitch.tv/membership twitch.tv/tags twitch.tv/commands');
  ws.send(`PASS oauth:${TOKEN}`);
  ws.send('NICK your-bot-name');
});

ws.on('message', (data) => {
  console.log('received: %s', data);
});

ws.on('close', () => console.log('Closed connection'));

Notice the NICK your-bot-name part. Make sure to replace this with the name of your bot.

Joining a chat

To test our bot, we'll be joining our own bot's chat. To see this, visit your profile on Twitch and navigate to your chat.

After you've done that, inside your open event, we're going to join this chat by sending 'JOIN #your-bot-name'. To see if it all works, we'll immediately send a message once we do, by also sending 'PRIVMSG #your-bot-name :Hey! I am here!'. The # is important in both messages, so don't forget those. Your code should look like this now:

// index.js
import WebSocket from 'ws';

const TOKEN = 'your token here';
const ws = new WebSocket('wss://irc-ws.chat.twitch.tv:443');


ws.on('error', () => console.error());

ws.on('open', () => {
  console.log('Opened connection');

  ws.send('CAP REQ :twitch.tv/membership twitch.tv/tags twitch.tv/commands');
  ws.send(`PASS oauth:${TOKEN}`);
  ws.send('NICK your-bot-name');

  ws.send('JOIN #your-bot-name');
  ws.send('PRIVMSG #your-bot-name :Hey! I am here!');
});

ws.on('message', (data) => {
  console.log('received: %s', data);
});

ws.on('close', () => console.log('Closed connection'));

You can now try your code in your terminal by running node index.js. If all goes well, you should be able to see messages stream in through your terminal, but you should also see the message "Hey! I am here!" in your Twitch chat in your browser.

If you send a message in chat, you should also see it inside your terminal.

Responding to messages

In order to properly respond to messages, you'll need to look into parsing them. Twitch has a great example on this. But for now, let's just make a very very simple response to when someone says "Hi bot!".

To do this, inside the message listener, we'll check wether or not an incoming message has the string ":Hi bot". if it does, we'll respond with a message. Your code will look like this:

// index.js
import WebSocket from 'ws';

const TOKEN = 'your token here';
const ws = new WebSocket('wss://irc-ws.chat.twitch.tv:443');


ws.on('error', () => console.error());

ws.on('open', () => {
  console.log('Opened connection');

  ws.send('CAP REQ :twitch.tv/membership twitch.tv/tags twitch.tv/commands');
  ws.send(`PASS oauth:${TOKEN}`);
  ws.send('NICK your-bot-name');

  ws.send('JOIN #your-bot-name');
  ws.send('PRIVMSG #your-bot-name :Hey! I am here!');
});

ws.on('message', (data) => {
  console.log('received: %s', data);
  if (data.includes(':Hi bot')) {
        ws.send('PRIVMSG #your-bot-name :Hey you, how are you doing?');
    }
});
ws.on('close', () => console.log('Closed connection'));

Try restarting your code again by doing node index.js inside your terminal. Once you've connected, visit your Twitch chat in your browser again and type "Hi bot". If all works well, you should now see that the bot responds with "Hey you, how are you doing?".

This was a very very small tutorial on how to make a simple chat bot. Feel free to play around with it as you go!

Forem: Karin

Deploy your bolt.new app to Netlify

True color with an explainer on bits and bytes

Bits and Bytes

Bit

Byte

True color can render RGB

RGB

Conclusion

Netlify integrations can now inject serverless functions to enhance any site. Here’s how

TL;DR

Prerequisites

Let’s get started

Deploy the integration

Check out the integration code

Check out the integration code

Different function options

Serverless function

What can you use a serverless function for?

How do you create a serverless function?

How do you use a serverless function?

Background function

What can you use a background function for?

How do you create a background function?

How do you use a background function?

Scheduled function

What can you use a scheduled function for?

How do you create a scheduled function?

How do you use the scheduled function?

What’s next?

More information

Create an integration that injects edge functions into any site

TL;DR

Prerequisites

Let's get started

Deploy the integration

Customizing

Testing

Add an integration UI

Other things to try and more information

Find your module's location

import.meta.url

__dirname

Why not just use process.cwd()?

Getting the actual directory

Modern Node.js

Using the directory

Send data to a node.js server with FormData, a comprehensive guide.

Different content types for sending data

text/plain

application/x-www-form-urlencoded

application/json

multipart/form-data

Diving into FormData

Creating a FormData object

Available methods on FormData

Sending a FormData object to a server

Receiving FormData on the server

Without a file upload

With a file upload

What is the difference between HTTP versions?

What is HTTP?

Where is it used?

Why are there different versions?

HTTP/0.9

HTTP methods

Headers

HTML

HTTP/1.0

HTTP methods

Headers

Caching

Status codes

HTTP/1.1

Persistent connections and lower latency

Chunks

Host

HTTP/2

Multiplexing

Compressing headers

`import.meta.url`

`__dirname`

Why not just use `process.cwd()`?

`text/plain`

`application/x-www-form-urlencoded`

`application/json`

`multipart/form-data`