DEV Community: Jake Partusch

Introducing Serverless UI: A command-line utility for deploying serverless applications to AWS

Jake Partusch — Thu, 25 Feb 2021 12:42:38 +0000

Serverless UI

💻 🚀 ☁

Deploying Websites to AWS on Easy Mode

Serverless UI is a free, open source command-line utility for quickly building and deploying serverless applications on AWS

Bring your own UI It doesn't matter if it's React, Vue, Svelte or JQuery. If it compiles down to static files, then it is supported.
Serverless Functions Your functions become endpoints, automatically. Serverless UI deploys each function in your /functions directory as a Node.js lambda behind a CDN and API Gateway for an optimal blend of performance and scalability.
Deploy Previews Automatically deploy each iteration of your application with a separate URL to continuously integrate and test with confidence.
Custom Domains Quickly configure a custom domain to take advantage of production deploys!
TypeScript Support Write your serverless functions in JavaScript or TypeScript. Either way, they'll be bundled down extremely quickly and deployed as Node.js 14 lambdas.
Own your code Skip…

View on GitHub

Deploying Websites to AWS on Easy Mode

Serverless UI is a free, open source command-line utility for quickly building and deploying serverless applications on AWS

Bring your own UI It doesn't matter if it's React, Vue, Svelte or JQuery. If it compiles down to static files, then it is supported.
Serverless Functions Your functions become endpoints, automatically. Serverless UI deploys each function in your /functions directory as a Node.js lambda behind a CDN and API Gateway for an optimal blend of performance and scalability.
Deploy Previews Automatically deploy each iteration of your application with a separate URL to continuously integrate and test with confidence.
Custom Domains Quickly configure a custom domain to take advantage of production deploys!
TypeScript Support Write your serverless functions in JavaScript or TypeScript. Either way, they'll be bundled down extremely quickly and deployed as Node.js 14 lambdas.
Own your code Skip the 3rd Party services — get all of the benefits and security of a hosted AWS application, without going through a middleman. Deploy to a new AWS account, or an existing account and get up and running in five minutes!

🚀 Get Up and Running in 5 Minutes

You can get a new Serverless UI site deployed to you AWS account in just a few steps:

AWS Prerequisites

In order to deploy to AWS, you'll have to configure your machine with local credentials. You'll find the best instructions here.

Install the AWS CDK.

   npm install -g aws-cdk

Install the Serverless UI Command-Line Interface

   npm install -g @serverlessui/cli

Bootstrap your AWS Environment

Next, specify your account and region to bootstrap the CDK environment for quicker subsequent deployments

   cdk bootstrap aws://ACCOUNT-NUMBER-1/REGION-1

Deploy your static website

Finally, tell the Serverless UI where to find your website's static files

   sui deploy --dir="./dist"

That's It!

Enjoy your serverless application, deployed on your own infrastructure.

Introducing Lumberjack: an Automated Accessibility Scanner

Jake Partusch — Tue, 11 Feb 2020 13:28:25 +0000

Lumberjack

Chop down accessibility issues with this full-website accessibility scanner

About

Lumberjack runs axe accessibility checks on your entire website!

Reads your website's sitemap
Spawns multiple browser instances and starts scanning with axe
Aggregates results and reports back

Usage

CLI

NPX (recommended for a single run)

npx @jakepartusch/lumberjack --url https://google.com

Global Install (recommended for multiple runs)

npm install -g @jakepartusch/lumberjack
lumberjack --url https://google.com

Options

--url         // Required — The base url to scan. If a sitemap exists, its pages will be scanned as well
--strict      // Optional (default: false) — Fail the process if any accessibility issues are found
--baseUrlOnly // Optional (default: false) — Skip the sitemap scan and only run the audit on the base url

JavaScript

npm install @jakepartusch/lumberjack

const lumberjack = require('@jakepartusch/lumberjack')
const myFunction = async () => {
  const results = await lumberjack("https://google.com")
  console.log(results);
}

Continuous Integration

GitHub Actions Example (eg. ".github/workflows/accessibility.yml")

name: Accessibility Audits

…

View on GitHub

Accessibility testing is hard. And for the most part, accessibility testing is also manual. Testers interact with their websites with not only their keyboards, but also with multiple screen readers and browsers. Luckily, with static html analysis and pin-pointed JavaScript execution, we can detect a subset of accessibility issues with automated tools 🎉.

We can automatically find issues like:

Poor color contrast
Heading levels out of order
Buttons and links without accessible text
Inputs without labels

Using automation, we can quickly find accessibility issues and prevent future regressions!

Axe

Axe is an accessibility tool that has gained a lot of traction over the past few years. And it even has a Chrome extension!

Axe is great, but can only be run on a single page at a time. So, let's extend the power of axe to level-up our accessibility game!

Lumberjack

Lumberjack uses the power and rulesets of axe, but orchestrates the scanning of many pages simultaneously.

Lumberjack can scan 100 individual pages in under two minutes!

Here is how Lumberjack works:

You give lumberjack a url (eg. https://google.com)
Lumberjack reads your website's sitemap
It spawns multiple browser instances and starts scanning with axe
It aggregates results and reports back

Even better, this can all be triggered with a single command

npx @jakepartusch/lumberjack --url https://google.com

Lumberjack CI

Finally, we can integrate Lumberjack into our continuous integration pipeline to ensure that we aren't introducing any new accessibility issues into our websites.

An Example with GitHub Actions (eg. ".github/workflows/accessibility.yml")

name: Accessibility Audits

on: [push]

jobs:
  build:
    runs-on: ubuntu-18.04

    steps:
      - uses: actions/checkout@v1
      - name: Install required Linux packages
        run: |
          sudo apt-get update
          sudo apt-get install libgbm-dev
          sudo apt-get install xvfb
      - name: Use Node.js 12.x
        uses: actions/setup-node@v1
        with:
          node-version: 12.x
      - name: Install npm packages
        run: |
          npm ci
      - name: Build
        run: |
          npm run build
      - name: Accessibility Audits
        run: |
          npm install -g @jakepartusch/lumberjack
          xvfb-run --auto-servernum lumberjack --url https://google.com

As a community let's build accessibility tooling as often and with as much fervor as we build IDE themes :). Together, we can make the web a better place ♥️.

For more info, and documentation, visit https://github.com/JakePartusch/lumberjack

The Best Way to Automate Performance Checks in GitHub

Jake Partusch — Wed, 15 Jan 2020 12:49:59 +0000

We all want to build fast websites. But we don't want to manually run performance checks on every build. Right? Moving performance checks into a continuous integration process removes this manual audit and alerts us when the web performance of our application may be degrading. In this article, we'll discuss a great way to automate performance checks in GitHub projects with Lighthouse, Page Speed Insights and GitHub Actions.

Lighthouse

Google's Lighthouse is an open-source, automated tool for improving the quality of web pages. Lighthouse can be run locally with developer tools, or remotely via web.dev and provides users with 5 distinct scoring categories.

Performance
Accessibility
Best Practices
SEO
Progressive Web App

An overall score is given for each category along with issues and recommendations to improve the scores.

Running Lighthouse in Chrome Dev Tools or on web.dev is great, but in order to automate this process, we'll need a command line interface (CLI).

Lighthouse CLI

Google also provides a CLI for running Lighthouse on a local machine or a build server. The great thing about the CLI is that it can be run against a live site, or local build directory.

Running Lighthouse CLI on a live website

After globally installing (npm install -g @lhci/cli) the npm package, we can use the lhci script to trigger Lighthouse audits. By using --upload.target and --collect.url, we can run the audit against a URL and have the HTML result uploaded to a temporary web page.

$ lhci autorun --upload.target=temporary-public-storage --collect.url=https://jake.partus.ch
✅  .lighthouseci/ directory writable
⚠️   Configuration file not found
✅  Chrome installation found
Healthcheck passed!

Running Lighthouse 3 time(s) on https://jake.partus.ch
Run #1...done.
Run #2...done.
Run #3...done.
Done running Lighthouse!

Uploading median LHR of https://jake.partus.ch/...success!
Open the report at https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1578972923376-47459.report.html
No GitHub token set, skipping.

Done running autorun.

Running Lighthouse CLI on a local directory

If a URL is not specified, the CLI will attempt to find the static build directory and host the application on a local web server. In the following example, it was able to determine that the build directory was named public, host the website on port 52259, and then run the audits against the local build.

$ lhci autorun --upload.target=temporary-public-storage
✅  .lighthouseci/ directory writable
⚠️   Configuration file not found
✅  Chrome installation found
Healthcheck passed!

Automatically determined ./public as `staticDistDir`.
Set it explicitly in lighthouserc.json if incorrect.

Started a web server on port 52259...
Running Lighthouse 3 time(s) on http://localhost:52259/404.html
Run #1...done.
Run #2...done.
Run #3...done.
Running Lighthouse 3 time(s) on http://localhost:52259/index.html
Run #1...done.
Run #2...done.
Run #3...done.
Done running Lighthouse!

Uploading median LHR of http://localhost:52259/404.html...success!
Open the report at https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1578972840850-69068.report.html
Uploading median LHR of http://localhost:52259/index.html...success!
Open the report at https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1578972841932-44445.report.html
No GitHub token set, skipping.

Done running autorun.

Page Speed Insights

Page Speed Insights is another tool created by Google which combines Lighthouse performance scores with real-world performance data.

For more in-depth information on the benefits and APIs available via Page Speed Insights, read this 👇

Monitoring Performance with the PageSpeed Insights API

Addy Osmani ・ Jan 6 '20

#pagespeedinsights #webperf #monitoring #webdev

Page Speed Insights focuses solely on the performance aspects of a webpage. While this is useful, we should try to utilize both Lighthouse and Page Speed Insights to get a complete picture on the performance and other characteristics of our website.

GitHub Actions

GitHub Actions makes it easy to automate all your software workflows, now with world-class CI/CD. Build, test, and deploy your code right from GitHub.

GitHub Actions is a new product from GitHub which allows the configuration of a custom CI/CD pipeline for your project. GitHub Actions can be run for individual pull requests, whenever code is pushed, or a whole host of other events.

Running Lighthouse with a GitHub Action

Here is an example of GitHub Action script to run an audit on every pull request. To get started, put the following yaml config in a file in your project at .github/workflows/audit.yml. The checkout, install, and build scripts may need to be tweaked depending on the specifics of your application.

name: Performance Audit

on: [pull_request]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v1
      - name: Use Node.js 12.x
        uses: actions/setup-node@v1
        with:
          node-version: 12.x
      - name: Install
        run: |
          npm ci
      - name: Build
        run: |
          npm run build
      - name: Run Lighthouse CI
        run: |
          npm install -g @lhci/cli@0.3.x
          lhci autorun --upload.target=temporary-public-storage

Configuring a GitHub App for integrated status checks (Optional)

In order to get integrated GitHub status checks, the Lighthouse CI GitHub app must be installed and configured.

Then, the token must be added to the projects "Secrets".

Finally, the build script can be tweaked to reference the secret.

      - name: Run Lighthouse CI
        run: |
          npm install -g @lhci/cli@0.3.x
          lhci autorun --upload.target=temporary-public-storage"
        env:
          LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}

After all of this is configured, the status checks should now be created by the Lighthouse CI GitHub App.

Adding PSI to the GitHub Action Script

To help to quickly and easily run PSI checks, I created a GitHub Action 🎉. In the following example, we'll add the PSI check to the end of our performance audit script.

name: Performance Audit

on: [pull_request]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v1
      - name: Use Node.js 12.x
        uses: actions/setup-node@v1
        with:
          node-version: 12.x
      - name: Install
        run: |
          npm ci
      - name: Build
        run: |
          npm run build
      - name: Run Lighthouse CI
        run: |
          npm install -g @lhci/cli@0.3.x
          lhci autorun --upload.target=temporary-public-storage
        env:
          LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}
      - name: Running Page Speed Insights
        uses: jakepartusch/psi-action@v1
        with:
          url: https://jake.partus.ch

While this is definitely useful, we might want to run our performance checks against a deploy preview of our application, so we can insure that we catch the performance regressions before we merge the PR.

Integrating with PR Previews

For this example we'll utilize Netlify for Pull Request Deploy Previews. After configuring deploy previews, Netlify will build and deploy the site when a PR is opened. The site will exist at the URL (deploy-preview-42--yoursitename.netlify.com). Since the deploy preview takes some time to process, I wrote another GitHub Action 🎉 to wait until the preview URL is available. Here is a complete example of a deploy preview performance audit with GitHub Actions.


name: Performance Audit

on: [pull_request]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v1
      - name: Use Node.js 12.x
        uses: actions/setup-node@v1
        with:
          node-version: 12.x
      - name: Install
        run: |
          npm ci
      - name: Build
        run: |
          npm run build
      - name: Waiting for 200 from the Netlify Preview
        uses: jakepartusch/wait-for-netlify-action@v1
        id: waitFor200
        with:
          site_name: "yoursitename"
      - name: Lighthouse CI
        run: |
          npm install -g @lhci/cli@0.3.x
          lhci autorun --upload.target=temporary-public-storage --collect.url=${{ steps.waitFor200.outputs.url }}
        env:
          LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}
      - name: Running Page Speed Insights
        uses: jakepartusch/psi-action@v1
        with:
          url: ${{ steps.waitFor200.outputs.url }}

Conclusion

Now we have a complete suite of performance audits that run with each Pull Request in GitHub 💯. To see all of this in practice, feel free to visit my personal website repo.

Reference Links

Lighthouse CI
Lighthouse CI GitHub status checks
Page Speed Insights (library)
Page Speed Insights GitHub Action (shameless plug)
Wait for Netlify GitHub Action (shameless plug)

How to create a button with a div in React (and why you shouldn't)

Jake Partusch — Mon, 06 Jan 2020 15:22:08 +0000

As web developers, we are often tasked with creating various interactive components in our web applications. On occasion, it might seem like a tempting solution to add a click handler to an existing div, or to create a custom <Button/> component out of non-semantic elements.

// Detect dark theme var iframe = document.getElementById('tweet-1176161245352927237-50'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1176161245352927237&theme=dark" }

In this article I hope to illustrate the "hidden" bugs that are created by not using a button as a button and the amount of code that is required to overcome these deficits.

1. onClick handler

This is the obvious first step to add an interaction to a div. But, as its name suggests, the onClick handler on a div only supports mouse click events (onClick with a button does much more). Unfortunately, only supporting mouse events leaves keyboard and screen reader users in the dark. They are not informed that this has become an actionable element and they are also not able to trigger the interaction with the keyboard.



//DO NOT USE: non-accessible implementation
const Button = () => {
  const onClick = () => console.log('clicked');

  return <div onClick={onClick}>My Button</div>
}

2. Adding a Role, tabindex

We can inch towards and accessible solution by adding a tabindex and a role to the div. The button role will tell screen readers to announce this element as a button, and hint that it is actionable. Setting the tabindex="0" (tabIndex={0} in React), allows this element to be focused by the keyboard. Even so, our custom div can still not be triggered by the keyboard.

// Detect dark theme var iframe = document.getElementById('tweet-1183020913509502978-779'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1183020913509502978&theme=dark" }



//DO NOT USE: non-accessible implementation
const Button = () => {
  const onClick = () => console.log('clicked');

  return <div role="button" tabIndex={0} onClick={onClick}>My Button</div>
}

3. Keyboard events

When a button is focused, it can be triggered by either the SPACE or ENTER key. To bring this functionality to our div button, we need to implement onKeyPress and watch for those specific events. Then, we can manually forward matching events to our onClick handler.

By implementing these first three steps, our div button is now mostly accessible.



const Button = () => {
  const onClick = () => console.log("clicked");

  const onKeyPress = e => {
    const enterOrSpace =
      e.key === "Enter" ||
      e.key === " " ||
      e.key === "Spacebar" ||
      e.which === 13 ||
      e.which === 32;
    if (enterOrSpace) {
      e.preventDefault();
      onClick(e);
    }
  };
  return (
    <div
      role="button"
      onClick={onClick}
      tabIndex={0}
      onKeyPress={onKeyPress}
    >
      My Button
    </div>
  );
};

4. Disabled state

Oftentimes, the disabled attribute is used for preventing user interaction with a button. We can add that same functionality to our div button by setting the tabindex to -1 (which removes it from keyboard focus) and by ignoring any clicks in our onClick handler while the button is disabled.



const Button = ({ disabled }) => {
  const onClick = () => {
    if (disabled) {
      return;
    }
    console.log("clicked");
  };

  const onKeyPress = e => {
    const enterOrSpace =
      e.key === "Enter" ||
      e.key === " " ||
      e.key === "Spacebar" ||
      e.which === 13 ||
      e.which === 32;
    if (enterOrSpace) {
      e.preventDefault();
      onClick(e);
    }
  };
  return (
    <div
      className={disabled ? "btn disabled" : "btn"}
      role="button"
      tabIndex={disabled ? -1 : 0}
      onClick={onClick}
      onKeyPress={onKeyPress}
    >
      My div Button
    </div>
  );
};

5. Button Styles

If we also want to style our div to look like a button we can steal the default styles from Chrome (not recommended).



//DO NOT USE: browser-specific styles
.btn {
  display: inline-block;
  -webkit-appearance: button;
  padding: 1px 7px 2px;
  cursor: default;
  font: 400 11px system-ui;
  color: buttontext;
  background-color: buttonface;
}
.btn.disabled {
  color: rgb(170, 170, 170);
}

Conclusion

I think that the easiest way to illustrate the differences between creating a button out of a div and using an actual button is to show the amount of code required to implement all of the above (and more) with the following button snippet.



// PLEASE USE: most accessible solution
const Button = props => {
  const onClick = () => {
    console.log("clicked");
  };

  return (
    <button
      onClick={onClick}
      {...props}
    >
      My button Button
    </button>
  );
};

Quick Tips for Using a Screen Reader (VoiceOver) on a Mac

Jake Partusch — Sat, 28 Dec 2019 19:33:27 +0000

What is VoiceOver?

VoiceOver is a free screen reader built into Apple products (MacOS, iOS, etc). Screen readers are used by visually impaired users to navigate through content on their device(s).

As a web developer, it is vital that testing with a screen reader is part of the development workflow – much like running a linter, writing tests, or adjusting mobile responsiveness. Screen readers are a surprisingly large part of the web's user-base. It is estimated that between 1-2% of internet users in the United States use screen readers (~4 million) 😲.

A great first step in finding accessibility issues in a website is by becoming familiar with and using a screen reader on a consistent basis. Since VoiceOver comes pre-installed on MacOS, there is no need to download or configure a third party application!

Starting VoiceOver

For the purposes of this article, we'll focus on using VoiceOver with MacOS. VoiceOver works best with Safari, but also works well with both Chrome and Firefox. Luckily, starting VoiceOver is super simple:

Turn VoiceOver on/off → ⌘ + F5

After selecting "Use VoiceOver" the computer will start speaking the highlighted item on your focused application (black outline) while also providing a dialog box with the current transcript. At this point, the selected item on the screen can be changed by navigating with mouse. Feel free to click around to get a feel for the announcement of different types of elements.

VoiceOver Keys

The VoiceOver command keys (VO) are required to interact with VoiceOver shortcuts:
⌃ + ⌥ (Control + Option)
or
⇪ (Caps Lock)

The following shortcuts will utilize the VoiceOver command keys to interact with VoiceOver.

Navigation

Read next item → VO + Right Arrow
Read previous item → VO + Left Arrow

With these two commands, it is possible to navigate through the entire website as a VoiceOver user would. Screen readers not only focus on buttons and links, but also elements with text content.

After using VoiceOver navigation, it may quickly be apparent that some items on the website are not announced in a meaningful way. This is a great opportunity to read up on WAI-ARIA and WCAG 2.1. As web developers, we want our web applications to be usable by as many people as possible – fixing accessibility issues is often quick and extremely helpful to our screen reader users.

Useful Shortcuts

The following shortcuts are not mandatory for using VoiceOver, but can be useful for quickly navigating through an application (rather than pressing the right arrow 1 million times 😉).

Lock into Command Mode

Optionally, it is possible to lock into VoiceOver command mode, with the following shortcut:

Lock into command mode → VO + ;

After locking into command mode, it is not necessary to use the VoiceOver command keys, but this will restrict the ability to type normally as many keys are tied to VoiceOver shortcuts.

VoiceOver Rotor

The Rotor allows the user to quickly navigate to different sections of the website and provides a useful widget to visualize the content of the web page. Navigation within the rotor can be accomplished with the arrow keys.

Start the Rotor →VO + U

Navigation Shortcuts

Although this can also be accomplished with the rotor, sometimes it is useful to navigate to headings or links with the following commands:

Next Heading → VO + ⌘ + H
Previous Heading → VO + ⌘ + ⇧ + H
Next Link → VO + ⌘ + L
Previous Link → VO + ⌘ + ⇧ + L

Useful Links/Further Reading

W3 references
WAI-ARIA
WCAG 2.1

VoiceOver references
VoiceOver complete command list
Deque's printable quick reference PDF

Accessibility Testing
aXe Accessibility testing tool

DEV Community: Jake Partusch

Introducing Serverless UI: A command-line utility for deploying serverless applications to AWS

JakePartusch / serverlessui

A command-line utility for deploying serverless applications to AWS. Complete with custom domains, deploy previews, TypeScript support, and more.

Serverless UI

💻 🚀 ☁

Deploying Websites to AWS on Easy Mode

Deploying Websites to AWS on Easy Mode

🚀 Get Up and Running in 5 Minutes

That's It!

Introducing Lumberjack: an Automated Accessibility Scanner

JakePartusch / lumberjack

An automated website accessibility scanner and cli

Lumberjack

About

Usage

CLI

Options

JavaScript

Continuous Integration

Axe

Lumberjack

Lumberjack CI

The Best Way to Automate Performance Checks in GitHub

Lighthouse

Lighthouse CLI

Running Lighthouse CLI on a live website

Running Lighthouse CLI on a local directory

Page Speed Insights

Monitoring Performance with the PageSpeed Insights API

Addy Osmani ・ Jan 6 '20

GitHub Actions

Running Lighthouse with a GitHub Action

Configuring a GitHub App for integrated status checks (Optional)

Adding PSI to the GitHub Action Script

Integrating with PR Previews

Conclusion

Reference Links

How to create a button with a div in React (and why you shouldn't)

1. onClick handler

2. Adding a Role, tabindex

3. Keyboard events

4. Disabled state

5. Button Styles

Conclusion

Quick Tips for Using a Screen Reader (VoiceOver) on a Mac

What is VoiceOver?

Starting VoiceOver

VoiceOver Keys

Navigation

Useful Shortcuts

Lock into Command Mode

VoiceOver Rotor

Navigation Shortcuts

Useful Links/Further Reading