Quick introduction to Lighthouse CI and how it can be used in your GitHub Actions workflows for CI



I've noticed that despite [Lighthouse](https://developer.chrome.com/docs/lighthouse/overview/) being one of the most widely used web development tools, Google's [Lighthouse CI](https://github.com/GoogleChrome/lighthouse-ci) really isn't used as frequently as I believe it should in CI workflows. Having a decent Lighthouse score is a must for any [accessible](https://developer.mozilla.org/en-US/docs/Web/Accessibility), SEO-friendly, performant website. Why shouldn't checks against it sit alongside your lint and type checks? 

Following Lighthouse CI's [Getting Started](https://github.com/GoogleChrome/lighthouse-ci/blob/main/docs/getting-started.md) guide is the easiest way to set it up. There's too many configuration options to discuss, so I encourage you to check that article out.


Essentially, though, you're only dealing with two files: (1) the [Lighthouse configuration file](https://github.com/GoogleChrome/lighthouse-ci/blob/main/docs/configuration.md) and (2) your [GitHub Actions workflow](https://docs.github.com/en/actions/using-workflows). I've included an example of each below.

<CodeBlock filename="lighthouserc.json" lang="json">
{`
{
    "ci": {
        // ...
        "assert": {
            "preset": "lighthouse:no-pwa",
            "assertions": {
                "categories:performance": [
                    "error",
                    {
                        "minScore": 0.9
                    }
                ],
                "categories:accessibility": [
                    "error",
                    {
                        "minScore": 1.0
                    }
                ]
            },
            // ...
        }
    }
}
`}
</CodeBlock>

<br />

<CodeBlock filename=".github/workflows/ci.yml" lang="yaml">
{`
name: CI
on:
    pull_request:
        branches:
            - main
concurrency:
    group: $\{\{ github.head_ref || github.run_id \}\}
    cancel-in-progress: true
jobs:
    ci:
        runs-on: ubuntu-22.04
        timeout-minutes: 30
        steps:
            - uses: actions/checkout@v3
            - uses: actions/setup-node@v3
              with:
                  node-version: '18.14.2'

            - name: Install
              run: |
                  npm ci

            - name: Run Lighthouse
              id: lighthouse
              continue-on-error: true
              run: |
                  npx lhci autorun
`}
</CodeBlock>

After setup is complete, all that's left to to do is enter your repo's settings and [add a ruleset](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/managing-rulesets-for-a-repository) to your default branch that requires `ci` pass before any pull request can be merged.

<AiImage src="/articles/cover/illustrated_document_flow_05.png" prompt="Illustrated, document flowing into database" engine="Midjourney" />


Incorporating Lighthouse into Your CI Workflows 


A simple form backend powered by a Notion database and a Cloudflare Worker


<AiImage src="/articles/cover/redis_Illustrated_document_flowing_into_database_31814b1d-d60f-439b-97e6-002f6ecd01ec.png" prompt="Illustrated, document flowing into database" engine="Midjourney" />

We're excited to introduce [NotiFlare Forms](https://github.com/logram-llc/notiflare-forms), an open-source project that streamlines connecting your forms to a [Notion](https://notion.so/) database using [Cloudflare Workers](https://workers.cloudflare.com/).

When we started this website, we needed an inexpensive server to handle form data from our ["contact us" page](https://logram.io/contact). We didn't want to grapple with a database or an expensive SaaS product (e.g. [Netlify Forms](https://www.netlify.com/products/forms/)). And we couldn't rely on the backend serving this site because it's tied to Cloudflare's limited [Cloudflare Pages](https://pages.cloudflare.com/).

Since Notion powers most of our business and has a convenient [public API](https://developers.notion.com/), we thought that was our best option. After an hour, we had an MVP out:

<CodeBlock lang="typescript">
{`
import { Client } from "@notionhq/client"

function error(errors: string[]): Response {
    return new Response(JSON.stringify({ errors, success: false }), { 
        headers: {
            'Content-type': 'application/json'
        }
    });
}

interface Submission {
  name: string;
  email: string;
  message: string;
  databaseID: string;
}

function notionPage({ databaseID, name, email, message }: Submission): any {
    return {
        parent: {
            database_id: databaseID
        },
        properties: {
            "Title": {
                "title": [
                    {
                        "text": {
                            "content": 'Form Submission'
                        }
                    }
                ]
            },
            "Email": {
                "email": email
            },
            "Name": {
                "rich_text": [
                    {
                        "text": {
                            "content": name
                        }
                    }
                ]
            },
        },
        children: [
            {
                "object": "block",
                "type": "paragraph",
                "paragraph": {
                    "rich_text": [
                        {
                            "type": "text",
                            "text": {
                                "content": message
                            }
                        }
                    ]
                }
            }
        ]
    }
}

export default {
    async fetch(
        request: Request,
        env: Env,
        ctx: ExecutionContext
    ): Promise<Response> {
        if (request.method.toUpperCase() !== "POST") {
            return error(["Only POST requests allowed."])
        }

        const formData = await request.formData()
        const name = formData.get("name")
        const message = formData.get("message")
        const email = formData.get("email")

        if ([name, message, email].filter((f: string|null|File) => !f).length > 0) {
            return error(["name, message, and email fields must contain a value."])
        }

        try {
            const notion = new Client({
                auth: env.NOTION_INTEGRATION_TOKEN,
            })

            await notion.pages.create(
                notionPage({ 
                    databaseID: env.NOTION_DATABASE_ID, 
                    name: name as string, 
                    email: email as string, 
                    message: message as string
                })
            )

            return new Response(null, {
                status: 204,
            });
        } catch(e: any) {
            return error([String(e)])
        }
    },
};
`}
</CodeBlock>

We sought to address two main problem points after the MVP in the project, which [ChatGPT](https://chat.openai.com/) dubbed *"Notiflare Forms"*:

1. Since we can pull the database schema from [Notion's API](https://developers.notion.com/reference/retrieve-a-database), the user should not have to define the schema themselves in code.
2. With `multipart/form-data`, we can support file uploads.

## How NotiFlare Forms Works

NotiFlare Forms uses Cloudflare Workers to manage form submissions, with a Notion database acting as a persistent store. To set it up, create a Notion integration, a Notion database with columns corresponding to your form's fields (or vice-versa), deploy a Cloudflare Worker, and point your form (or request) to the deployed Cloudflare worker.

After configuring the Cloudflare Worker and directing your form to the worker's URL, every valid submission will appear as a new entry in your Notion database.

On a form submission (or really any `multipart/form-data` POST request), NotiFlare Forms will do three primary things:
1. Verify the submission contains the configured `NOTION_REQUIRED_COLUMNS`.
2. Upload any files to an [R2](https://www.cloudflare.com/products/r2/) bucket, if configured.
3. Create a new Notion database entry page.

### Demo

<Image src="https://github.com/logram-llc/notiflare-forms/raw/main/.github/readme/demo.gif" width={800} height={556} alt="Demonstration of NotiFlare Forms" />

In the demo, we used the following HTML form pointed towards our Cloudflare worker. The `Name`, `Message,` and `Attachments` fields correspond to our Notion database's column names.
<CodeBlock lang="html">
{`
<form
  method="POST"
  action="https://our-cloudflare-worker/"
  enctype="multipart/form-data"
>
  <label>
    Name 
    <input type="text" name="Name" required />
  </label>
  <label>
    Message 
    <textarea type="text" name="Message" required></textarea>
  </label>
  <label>
    Attachments 
    <input type="file" multiple="" name="Attachments"/>
  </label>

  <button type="submit">Send</button>
</form>
`}
</CodeBlock>

## Benefits of NotiFlare Forms

    * **Simplicity**: No need to set up and manage servers or databases. NotiFlare Forms takes care of everything for you.
    * **Flexibility**: Design your form however you like and match the column names in your Notion database to your form's field names.
    * **Cost-effective**: Cloudflare Workers and Notion offer free tiers, making it possible to run your form backend without incurring any costs.
    * **Scalability**: Cloudflare Workers can handle many requests, ensuring your form backend can scale with ease.

## Upcoming Enhancements

We're excited about growing and improving this project further. Here are a few enhancements we have in mind for the future:
1. Presently, NotiFlare Forms supports only one Notion database per Cloudflare worker. However, there are no technical limitations that prevent us from accommodating multiple Notion databases.
2. Notion's database API requires a Notion user ID for the `People` column type, and as such NotiFlare Forms expects the same to be submitted through the form. We aim to enable NotiFlare Forms to look up the user ID on Notion when provided with an email address.
3. While we appreciate Cloudflare, it shouldn't be an essential requirement for running this project. As such, we plan to add support for AWS Lambda hosting. We also intend to support all S3-compatible APIs for file uploads to broaden developer options.

## Getting Started

To get started with NotiFlare Forms, head over to the [GitHub repository](https://github.com/logram-llc/notiflare-forms/) and follow the instructions in the README.

---

We'd love to hear your feedback, so if you have any questions or suggestions, please don't hesitate to reach out by creating a [GitHub issue](https://github.com/logram-llc/notiflare-forms/issues) or using our [contact form](/contact)!

Introducing Notiflare Forms



We recently ran into an issue where &mdash; boiled down &mdash; we had two servers:

1. A Node.js server that would authenticate API users via the `Authorization` header. It exposes an `/auth/verify` endpoint, which returns `2xx` if this header is valid.
2. A websocket server we had no control over with no authentication mechanism

How could we expose this websocket server without it being unprotected?

After researching a bit, we found Caddy has a directive called [forward_auth](https://caddyserver.com/docs/caddyfile/directives/forward_auth). We could leverage this to forward all requests to our upstream node server's token verification endpoint before they're passed along (if successful) to our upstream websockets server.

<CodeBlock filename="Caddyfile" lang="typescript">
{`
:9000

forward_auth {$UPSTREAM_NODE_SERVER} {
    uri /auth/verify
}

reverse_proxy {$UPSTREAM_WEBSOCKETS_SERVER} {
    header_up -Authorization
}
`}
</CodeBlock>

Now, by only exposing our Caddy server, we've essentially added auth to our websocket server.


TIL: Caddy's forward_auth Directive


This frontmatter description will appear below the title


Hey! We're a team of two specializing in creating custom internal software solutions for early-stage startups. We understand that as a startup, it's crucial to have efficient and reliable tools to help your business run smoothly.

Internal tools are an important aspect of any business, as they help streamline processes and improve efficiency. We have a deep understanding of the unique needs of startups and are skilled in creating solutions that are tailored to your specific requirements.

In addition to specializing in internal tools, we also offer a range of services to help startups get up and running quickly. This includes project planning, design, development, and testing. We understand that starting a new business can be overwhelming, so we strive to make the process as smooth and stress-free as possible for our clients.

As a small agency, we are able to offer personalized attention and flexibility that larger agencies may not be able to provide. We take the time to get to know your business and understand your specific needs, so we can create a software solution that meets your unique requirements.

We believe in building strong, long-term relationships with our clients, and we're excited to work with you and help your startup thrive. If you're interested in learning more about how we can help your business succeed, please don't hesitate to contact us.


Logram

Blog

Navigating the complexities of development together.

Refine blog by tags

Incorporating Lighthouse into Your CI Workflows

Introducing Notiflare Forms

TIL: Caddy's forward_auth Directive

Hello, World!

Want more?

Consider subscribing and we'll email you as soon as a new article is published.

Sitemap