Progressive Bundling Example

kj — Tue, 07 Apr 2020 19:29:27 +0000

This is a follow-up code example for this post introducing Progressive Bundling: Progressive Bundling Post.

Check out the live example here: Live Example

Let's step through a project that has progressive bundling enabled to see how you might be able to use this approach in your next project.

You can follow along at home with this repo: begin-examples/node-progressive-bundling

Alternatively you can deploy your own on Begin by clicking this link: Deploy to Begin

To see the Progressive Bundling pattern in action, open up your browser's development tools to watch the network as the page loads.

Watch for a request to be made for home.js, and you should see a 302 redirect to a bundled and fingerprinted version of that module.

Project overview

Now that we've seen it in action let's get acquainted with the project. This is a standard Architect serverless project and while you don't need to know Architect to follow along you might want to have arc.codes open in case any questions come up.

Let's start at the beginning and look at how to configure the project's infrastructure.

`.arc`

The project's .arc file is how we declare this app's infrastructure as code. We declare all of the app's HTTP Functions under the @http pragma.

@app
pb-example

@static
folder public

@http
get /
get /about
get /modules/:type/:module
get /cache
post /cache

@tables
data
  scopeID *String
  dataID **String
  ttl TTL

folder structure

├── src/
│   └── http/
│   │    └── get-index/
│   └── views/
│        └── modules/
│   └── shared/
└── .arc

`src/http`

This folder is where all the HTTP function's source code lives. Architect maps these HTTP Functions to the routes declared under the @http pragma in the app's .arc file.

By convention, get-index/ is mapped to the route '/' and serves https://yoursite/. Similarly, get-about is assigned to /about and serves https://yoursite/about. A post-cache route would accept posts from forms having the action attribute set to action="/cache".

`src/shared`

This folder is where you put code you want to share between functions. Any code placed inside src/shared will be available to require from @architect/shared.

`src/views`

This folder is where all of your shared view code lives. These files are copied to all the GET routes by default allowing you to share view code throughout your app. Any code placed inside src/views will be available to require from @architect/views.

Implementation

This example app implements the Progressive Bundling pattern with a few discrete steps.

cache lookup: First, we check to see if the file already exists in the cache. If it does, we return it.
bundle: Then if the requested file isn't already in the cache, we bundle it.
fingerprint: Next, we generate a fingerprint id and append it to the file name.
cache Then this new file is cached for subsequent requests.
redirect: Finally, we redirect to the newly cached file.

It is possible to create a fingerprint by using a hash of the bundled file's contents. Appending a fingerprint to the file name ensures that the file name is updated when the content of the bundle changes. Adding a fingerprint to the file name avoids getting an outdated file due to a cached version in the end user's browser or network.

Now that we know the steps let's follow a request for a module through to the bundled response.

The route we are going to focus on first is get /modules/:type/:module. This route passes a module type and module name to our HTTP Function as parameters on the request.

The folder for this route is generated by Architect the first time you start the sandbox server. The folder for this route replaces the colons ":" that defines a route to a system-friendly three zeros "000". This means that the route get /modules/:type/:module will generate the folder src/http/get-modules-000type-000module.

src/http/get-modules-000type-000module

// Check to see if file is in cache
let file = await read({ name })
// Bundle the file if it is not found in the cache
if (!file) {
  file = await bundle({ name })
}
// Redirect to the file
return redirect(`/_static/${ file }`)

The above code is where all the action is in this file. This code first looks to see if there is a cached version to send; if not, it bundles the requested file then redirects the request to the bundled version.

Let's look at how we have implemented the cache.

src/shared/cache-read.js

const data = require('@begin/data')
// check the cache manifest
let cache = await data.get({
  table: 'module-cache',
  key: name
})

In the previous code block, we look for the module by name in a table called module-cache then return the file if found. In this example, we use Begin data for simplicity, but any data store would work.

Next is the code responsible for bundling the file.

src/http/get-modules-000type-000module/bundle.js

// Get the path to this module on disk
let input = path({ name })
// Pass the file path to rollup
let bundle = await rollup.rollup({ input })
// Bundle together modules
let bundled = await bundle.generate({ format: 'esm' })

Above we look up the file and then pass it to rollup to bundle. Rollup was used in this example, but you could substitute the bundler of your choice.

One last stop at the redirect code before sending the response.

src/http/get-modules-000type-000module/302.js

module.exports = function redirect(location) {
  return {
    statusCode: 302,
    headers: { location }
  }
}

Pretty straight forward, but it's useful to see how to send any type of reponse with a status code.

Wrapping up

We stepped through a project implementing this pattern and looked at all the places this pattern can be customized to fit your own needs. This example illustrates how Progressive Bundling can be implemented but is by no means the end. You can apply this pattern in your way and with other outputs. We can't wait to see what you make!

Progressive Bundling

kj — Tue, 07 Apr 2020 19:29:18 +0000

A dynamic module bundling pattern for modern web development

Until recently, the use of JavaScript modules required a build step to make them run in the browser. Since the general availability of ES6 modules in browsers, it is possible to use JavaScript’s built-in module system. What this means is we no longer require a build step to be able to write modular code that runs in the browser natively. Modules also can benefit from the addition of parallel loading made available with HTTP/2.

As we all know, with every development choice, there are new considerations that ultimately emerge over time.

For instance, with a build-step based workflow, your build time can start to take longer, and your compiler configuration can become exceedingly more complex as your project’s source code grows.

Modules don’t require the overhead of a build step, which is great, but loading too many sub-modules at once can create a bottleneck that can increase the time it takes to load your web page completely.

It is possible to get a long way without running into this issue, but if it does arise, cutting down on requests can help.

Enter Progressive Bundling

This pattern uses a cloud function to optimize the amount of JavaScript sent to the browser by bundling together modules and their sub-modules, into a single request, on-demand. Bundling these files together cuts down on the number of files being loaded in parallel by the browser. This bundled file is then “fingerprinted,” or named with an appended id representing the file’s contents. We then cache this generated file with this fingerprinted name for subsequent requests. The request is then redirected with a 302 status code to the newly bundled, fingerprinted, and cached file.

What makes this progressive is that you can start with stock JavaScript for development, which is easier to debug, then layer on bundling with a cloud function, and a standard HTTP redirect for an optimized build if you ever need it.

A delicate balance

It is always important to audit your site performance to understand when to employ optimization. It is possible to cut down on requests, but end-up loading too large a file that ultimately negatively impacts performance. The best bet is to always load as little JavaScript as possible.

Take it farther

Think about how you could apply this approach to delivering other payloads such as CSS or icons. You could even add a transpiler if you wanted.

Check out the Progressive Bundling Example

Where we step through the code of an example app using this pattern. Deploy your own Progressive Bundling example app on Begin.

DEV Community: kj