I built a no-code alternative to Workbox

A couple of days ago, we finally released an exciting new Progressier feature which our customers have been relentlessly requesting since we launched our beta.

With our caching strategy builder, anyone who owns a web app can easily configure caching strategies -- with toggles and dropdown rather than complicated regex and hard-coded service workers.

Why should I care about caching strategies?

By default, browsers tend to cache resources somewhat unpredictably through the HTTP cache mechanism. You have little control over how resources are cached and updated.

Instead with the Cache interface available in service workers, you can define very precisely how each type of resource is fetched, cached and refreshed.

With the right strategies, you can:

1. make your app functional offline
2. improve load times
3. keep key resources fresh without having to use a versioning trick
4. decrease your server costs

Pretty cool, in theory. In practice? Not so easy. Earlier this year, Google nearly gave every web app developer an ultimatum: make your app work offline or lose the install functionality. As I postulated when they abandoned that plan, making a website work offline consistently is harder than most people think.

In 2021, most developers use Workbox -- a JavaScript library that abstracts the Fetch API and Cache API. Workbox simplifies things… but isn't quite simple enough yet to my taste. Testing strategies is a hassle. Hard-coding lists of URLs in a service worker isn't exactly future-proof. The order of your rules can lead to unexpected behaviors. And writing Regex is a notorious pain in the ass.

Caching is a minefield

CORS, preflight requests, opaque responses, cache-control headers… these are some of the concepts that make caching hard to grasp. They're abstract and opiniated -- and truthfully most developers don't really know about them.

So the challenge was double. First, how does one build a universal service worker that works with any domains and resources? And second, how does one build a user interface that doesn't have a learning curve for this inherently complicated process?

The key is that everyone deals with caching the same way: by copy-pasting code snippets from the Workbox site or the Google Dev Site and swapping sample values with their own variables. Progressier lets you define these variables with toggles and dropdowns instead of hard-coding them in your service worker.

Specify rules, choose a strategy, see matching resources, precache URLs, auto-retry them - all in one interface with inputs and toggles instead of code

And then there are variable-looking things that in our day and age just aren't needed anymore. One of the ways Progressier simplifies the process is by shielding you from them automatically. A good example of this is caching expiration dates.

A modern take on caching

You shouldn't have to worry about expiration dates anymore. Because caching expiration dates are no longer needed. They're an antiquated way of invalidating cached resources -- reminiscent from the time the only way to deal with caching was the unpredictable HTTP Cache interface.

With the Cache interface available in service workers, there's absolutely no need to set expiration dates anywhere. You have much better control on things now:

• You can keep resources systematically fresh by not using caching at all (Network Only)
• You can keep resources fresh but fall back to a cached version when the network isn't available (Network First)
• You can fetch resources from the cache first to reduce load times but systematically revalidate them every time (Stale-while-Revalidate)
• You can get resources from the cache and never revalidate them to reduce server costs (Cache First)

Caching strategies in plain English

With Progressier, you simply choose one of the strategies above and select which resources to apply it to. Examples of rules:
- "Apply Network First to all resources from cdn.whatever.com"
- "Apply Cache First to all Font files"
- "Apply Network Only to api.mydomain.com/very-important-data.json"
- "Apply Stale-While-Revalidate to all images hosted on my domain"

And because Progressier is a no-code tool, you specify these rules in plain English -- just the way I did it above. That may seem frivolous. But if you have to modify them two years from now, you'll be glad not to have to decipher a bunch of regular expressions.
You can also visualize how each of the strategies intercept your resources (as rules may have overlap).

A visual indicator tells you how many actual resources from your app match each of these strategies.

And all other caching features too

Caching strategies is the key to making a web app functional offline. For a complete offline experience, there are a few other mechanisms that one must know about as well.

Here are some of the things you can configure your web app to do automatically with a few clicks in Progressier:

• Precache resources required for your app to launch while offline
• Retry failed requests later when network connectivity is lost
• Build redundancy by providing fallback URLs for important resources
• Override headers that prevent caching (especially useful for no-code builders like Bubble).
• Show an offline alert to warn users that they've lost network connectivity

Simple is hard

Steve Jobs said "Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it's worth it in the end because once you get there, you can move mountains."

Building the user interface of a caching strategy builder might be the hardest simple thing I've ever had to do. And while Progressier definitely won't move mountains, it does put caching within reach of any developers -- whether they write code or use no-code builders. If this sounds interesting, you can try it for free here.