DEV Community: Jeff Posnick

Using npm modules inside of Apps Script

Jeff Posnick — Mon, 12 Jul 2021 04:00:00 +0000

I recently was processing some data using Apps Script, and needed to parse out second-level domain info from a bunch of URLs. This is definitely not the job for regular expressions, but it's perfect for an npm module, psl, that uses the public suffix list.

But while Apps Script has come a long way, and features lots of ES2015+ goodness nowadays, it's not possible to pull in arbitrary code from npm and run it directly.

To work around this, I created the following index.js file locally, exporting the interface that I wanted to call from Apps Script:

import psl from 'psl';
import Url from 'url-parse';

export function parseHostname(sourceURL) {
  const url = new Url(sourceURL);
  return psl.parse(url.hostname);
}

Then, I installed the necessary dependencies from npm, and bundled this code up with esbuild:

npm init -y
npm install --save-dev psl url-parse punycode
npx esbuild index.js --bundle --global-name=psl --outfile=psl.js

I manually copied the contents of the psl.js file into a psl.gs file, alongside my main Code.gs file in the Apps Script editor. (This would be annoying if the bundled output changed frequently, but doing it once by hand wasn't a problem.)

Apps Script will automatically make the contents of all .gs files in a project visible in the same global scope, so I could now write code like

const {sld} = psl.parseHostname(url);

inside of my main Code.gs file.

Caveats

The Apps Script runtime environment still has a bunch of quirks when compared to Node, so don't expect all of your bundled code to work as-is. Polyfills may be needed (I used url-parse, for instance, since the native URL object isn't available in Apps Script.)

Once you copy over the bundled code to Apps Script, it's never going to be updated, so make sure you're prepared to rebundle if and when there are any security or feature updates to the modules you're using.

Service workers in create-react-app v4+

Jeff Posnick — Tue, 22 Dec 2020 15:45:27 +0000

Ever since built-in support for service workers was added to create-react-app v2, developers have been asking for more control over the resulting service worker's functionality. This might mean disabling precaching in favor of solely runtime caching, or it might mean adding in push notification or web share target support.

create-react-app v4+ will check for the presence of a src/service-worker.js file at build time, and if found, run workbox-webpack-plugin's InjectManifest plugin, passing in that file as the swSrc parameter.

If you're starting a new project and follow the instruction from create-react-app's "Making a Progressive Web App" guide, i.e. you run npx create-react-app my-app --template cra-template-pwa, you'll end up with everything in the right place.

Which is to say your project will:

automatically bundle the code in src/service-worker.js (transforming the ES module imports into code that can be run inside the service worker)
look for the symbol self.__WB_MANIFEST somewhere inside your src/service-worker.js, and replace it with a precache manifest, consisting of URLs and revision info about all your webpack assets, so that Workbox can precache them.

If you're not interested in precaching your webpack assets, then you don't need to use the InjectManifest plugin at all, and you can just put whatever code you want in a file named anything other than src/service-worker.js, and register that file as your service worker. That's up to you.

If you are interested in Workbox's precaching, but you're upgrading from an older create-react-app and you don't have a "correct" src/service-worker.js file, you can manually copy the file from the template into your project.

(This post was adapted from a Stack Overflow response.)

Performance auditing an eCommerce site

Jeff Posnick — Mon, 06 Apr 2020 15:00:00 +0000

Alan's weekly eCommerce livestreams

My teammate Alan's been running a weekly livestream on his YouTube channel, focusing on topics of interest to eCommerce websites. He asked me to come on this week and perform a site performance audit.

Since I'm currently homebound due to Coronavirus concerns in NYC, I haven't had the chance to perform any in-person site audits in a while. Going through the process via a livestream was a great opportunity!

The site review

The review process took about 50 minutes (I'd recommend watching at 2x playback speed...) and covered some relevant findings from WebPageTest.org and Lighthouse.

We choose the site, https://threddies.com/, "at random" based on folks who volunteered. I think it ended up being fairly representative of the types of issues a lot of sites encounter.

Lightly edited from the notes I took during the review.

Tools used:

Observations

11 seconds for main content to load — what's loaded beforehand?
How many of the widgets/analytics tools can be lazily-loaded (or potentially removed, if appropriate)?
HTTP cache expiration best practices.
Use the Coverage panel in Chrome Dev Tools to evaluate how much of your JS/CSS in the critical request path is being used
Q: Can they get away with loading Google Maps static images instead of Google Maps widget? Answer: yes, they can.
Always click on the "Learn More" link in Lighthouse for additional context!
Zach Leatherman's guides to loading web fonts are great.

Exposing headers on CORS responses

Jeff Posnick — Mon, 22 Jul 2019 12:00:00 +0000

CORS and its discontents

The concept of CORS requests comes up a lot in my professional life. Much of the time, it's in the context of why a given response is opaque, and how to make that response non-opaque so that it plays nicely with service workers and the Cache Storage API.

Fortunately, many popular third-party APIs and hosts support CORS nowadays, and solving your basic CORS-related mystery normally boils down to, say, adding in the crossorigin attribute to your <img> tags.

When CORS is not enough

But while enabling CORS is enough to get back basic information about an HTTP response—like its status code, or access to its body—there's still some information that's locked down by default. The headers exposed on a CORS response, for instance, are limited to the following six "simple" response headers:

Cache-Control
Content-Language
Content-Type
Expires
Last-Modified
Pragma

Some of those headers can come in handy when accessed inside of a service worker, but there's one in particular that can be useful, but isn't exposed by default: Date.

In particular, if you're using Workbox's cache expiration logic and you provide a maxAgeSeconds parameter, the Date of the cached response is checked against the difference between the current time and maxAgeSeconds. If the Date is too old, then the cached response will end up being ignored.

But... this logic only works if there's a Date header exposed on the response. By default, that won't be the case for a CORS response.

Exposition

The workaround, as with so many things related to CORS, involves fiddling with HTTP response headers. You'll either need access to the underlying HTTP server yourself, or you'll need to reach out to your CDN/API provider asking them to make the change.

Setting Access-Control-Expose-Headers: Date will permit the Date response header to be visible to your web app's code, and you could include any additional headers there in a comma-separated list.

If you're using your own Express-based web server, the corser middleware looks pretty reasonable for setting up a working configu ration. Their docs include a recipe for configuring the exposed response headers.

Paying Attention while Loading Lazily

Jeff Posnick — Fri, 07 Jun 2019 17:53:30 +0000

What's all this?

This is an interactive project that explores what happens when loading best practices (hashed asset URLs, lazy-loading, service workers) meets single page app usage patterns (long-lived tabs, "fake" navigations via the History API) meets common deployment scenarios (redeployments that don't preserve old URLs).

If you're feeling particularly meta, you can watch a video walkthrough of this material:

How's it work?

Visit one of the loading scenarios below, and leave the page open.
In the Glitch editor, make a change to a component (like About.js)
Using the Glitch console, run webpack --config=path/to/webpack.config.js to rebuild the scenario you have open.
You've just "redeployed!" Navigate around the open scenario page see what works (and what doesn't).

(Updating the web app's JavaScript won't trigger an automatic rebuild, though updating server.js will.)

Loading scenarios to try

Learn more

Loading JavaScript

Service workers

HTTP serving

That time I used a generator

Jeff Posnick — Fri, 22 Mar 2019 12:00:00 +0000

Backstory

I moved over to work on Google's Web DevRel team way back in 2014, and one of the first tasks that I took on was writing short update articles and code samples for new web platform features. These are... somewhat embarrassing to look back on, so I won't link to many here, but one of the first I put together covered generators. I didn't have a huge amount to say about generators, so the general approach used in the article was to link to some more canonical resources,while calling out a couple of interesting "gotchas" that I thought could add some value.

So I wrote that, moved on, and then pretty much forgot that generators existed for the next 4 years.

Refactoring

That takes us to a few months ago, when I was working on a rewriteof the workbox-precaching module as part of the Workbox v4release. This gave me an opportunity to revisit some code that hadn't been touched in a while.

Original logic

The actual code isn't super-relevant (I'll link to the before and after below, for those who are interested), but the main points were:

It was code to compare a string against few possible matches.
Calculating each possible match is (somewhat) expensive.
The code returned true as soon as it found a match.
If none of the conditions matched, it returned false.

The original code looked something like:

const originalUrl = '...';
const urlToMatch = '...';

const urlVariation1 = generateVariation1(originalUrl);
if (urlToMatch === urlVariation1) {
  return true;
}

const urlVariation2 = generateVariation2(originalUrl);
if (urlToMatch === urlVariation2) {
  return true;
}

// etc.

return false;

I'm not a huge fan of a repeated sequence of if(...) { return ... } statements aesthetically, and structuring code like that can make it harder to understand that each test case is effectively doing the same thing.

Refactoring without generators

One potential refactoring to emphasize the repeated logic could be:

const originalUrl = '...';
const urlToMatch = '...';

const urlVariations = [
  generateVariation1,
  generateVariation2,
  // etc.
].map((generateVariation) => generateVariation(originalUrl));

for (const urlVariation of urlVariations) {
  if (urlToMatch === urlVariation) {
    return true;
  }
}

return false;

I like that version of the code from an aesthetic point of view, but one downside is that you end up running each of the generateVariationN() functions ahead of time. If a variation early in the list ends up matching, you've ended up running (potentially expensive) code for nothing.

Refactoring with generators

So! This is when I remembered that generators were A Thing, and could come in handy in this use case.

Generators are iterable,so it could be dropped right in to a for...of loop.

Generators only run when their next() value is requested: they'll execute until a yield keyword is encountered, at which point they pause and control goes back to whatever triggered the iteration. If we yield the results of our potentially expensive functions one at a time inside of a generator, we don't have to worry about executing functions whose results won't actually be needed. And we still get to structure the code that uses the values as a loop rather than a sequence of if(...) { return ...; } statements. It's the best of both worlds!

Using a generator and a for...of loop gives us code that looks something like:

function* generateVariations(originalUrl) {
  // You could put these yields inside a loop, too!
  yield generateVariation1(originalUrl);
  yield generateVariation2(originalUrl);
  // etc.
}

for (const urlVariation of generateVariations(originalUrl)) {
  if (urlToMatch === urlVariation) {
    return true;
  }
}

return false;

The actual changes in Workbox

If you're curious, the original code in Workbox v3 ishere.The v4 code has been split up into modules for the newgeneratorand thecode that loops over the generated values.

CDS Perf Review Clinic Takeaways

Jeff Posnick — Fri, 10 Nov 2017 12:00:00 +0000

CDS '17 Retrospective

Chrome Dev Summit 2017 is behind us. I spent most of the run-up to the event putting together my"Workbox: Flexible PWA Libraries" talk, but beyond that, I was also involved in running on-site Performance Review Clinics that attendees could sign up for.

It's always a privilege to meet with the developers who are building web apps that I use every day, and to lend whatever guidance I could offer. Looking into the performance of a large group of production websites gives insights that you wouldn't get from just examining a site as a one-off. Patterns start to emerge about common areas for improvement.

I wanted to publicly share a few high-level groupings based on those patterns, and identify a handful of links for each area that contain useful guidance. It's by no means exhaustive, but I can say that each of these links contains solutions to a real-world performance issue that we identified during the Performance Review Clinics.

Linkdump!

Huge thanks go out to all the authors, many of whom I'm lucky enough to work with.