DEV Community: Mike Healy

Using S3 Lifecyle Rules with Spatie Laravel Backups

Mike Healy — Fri, 14 Jul 2023 05:41:12 +0000

AWS S3 has a feature called Lifestyle Rules that let you define rules to run a range of transitions on your objects, such as changing their storage class or expiring (deleting) them.

This can be useful to save costs and clean up your object list by removing objects you don't need to keep forever.
You can lean on AWS for the expiry logic without having to program scheduled events to cleanup for you.

Lifecyle rules can be targeted to an entire bucket, to objects with a path prefix, or to objects with a particular Tags.

Spatie Laravel Backup is a popular Laravel package for taking site/database backups.

It can be configured to write to various 'disks'. If you're using the S3 disk it is possible to Tag those backups for targeting by the Lifecycle rule.

Creating the rules in S3 and targeting a tag

From your bucket, go to Management and create a Lifecyle rule.

In my case I will be targeting a tag called fadeout with a value of true.

This rule will transition objects to the Standard Infrequent Access storage class after 30 days, and then delete them after 60 days. It also only applies to objects over 150kB.

Tagging backups that Laravel Backup uploads

To have your backup objects tagged in order for the lifecycle rule to take effect you'll need to an an option to your Laravel fileysystems.php config file.

Assuming you are using the s3 disk, you'll need to add a backup_options value to your S3 config array like so:

's3' => [
  'driver' => 's3',
  'key' => env('AWS_ACCESS_KEY_ID'),
  'secret' => env('AWS_SECRET_ACCESS_KEY'),
  'region' => env('AWS_DEFAULT_REGION'),
  'bucket' => env('AWS_BUCKET'),
  'url' => env('AWS_URL'),
  'backup_options' =>
     ['Tagging' => 'fadeout=true', 'visibility'=>'private'],
],

Backups are private by default, but because we're overriding the options array we need to specify it again.
The format of the Tagging key is url encoded as shown.
The Tagging and visibility keys are case sensitive as shown.

With that in place you can keep your recent backups without cluttering your bucket :)

Running Jest with a Vue2 application

Mike Healy — Sun, 15 Jan 2023 03:38:31 +0000

The Vue CLI and test utils have a 'happy path' to setup testing libraries, but they are naturally geared to the latest version of Vue and other dependencies.

If you need to add tests to an existing Vue 2 application you might find the process a little tricky.

You'll need to install the version of Vue test utils and vue-jest that correspond to your version of Vue.

For example if you're running Jest 29, you'll need to install vue2-test like so:

npm install --save-dev @vue/test-utils@1 @vue/vue2-jest@29

Because the tests run in an environment without a native DOM we'll also need to configure them to use the jsdom implementation.

Install the package like so:

npm install --save-dev jest-environment-jsdom

Then configure Jest to use the virtual JS DOM. Jest can be configured either via a dedicated file, or through your package.json like so:

{
 // other config...

 "jest": {
        "testEnvironment": "jsdom",
        "moduleFileExtensions": [
            "js",
            "json",
            "vue"
        ],
        "setupFiles": [
            "./jest-setup.js"
        ],
        "transform": {
            "^[^.]+.vue$": "@vue/vue2-jest",
            ".*\\.(js)$": "babel-jest"
        }
    }
}

In my case I required some extra config that's loaded in jest-setup.js. This is because my app had global dependencies for LoDash and a utilities file. To make these functions available in the test environment they are loaded like this.

jest-setup.js

import lodash from 'lodash';
import utils from './resources/js/utils.js';

global._ = lodash;
global.utils = utils;

Dark Mode Toggle with Alpine & Tailwind

Mike Healy — Fri, 04 Jun 2021 22:56:45 +0000

Some users prefer darker colour themes to prevent eyestrain, while others like having the choice depending on their lighting conditions. Tailwind makes it easy to specify different colours to use depending on which mode is active.

By default Tailwind responds to the prefers-color-scheme media query, which passes through the users' operating system preference. You can also configure it to alter the colours by inheriting a 'dark' CSS class name from a parent element.
This lets you to build your own UI control to switch modes, so that users can have a different preference for your site than their OS.

To do this, change the darkMode property in your tailwind.config.js file

// tailwind.config.js
module.exports = {
  //...

  darkMode: 'class',
}

Controlling The Active Mode

Now that Tailwind is configured to compile dark mode colours based on the .dark class name, we need a way to toggle that class name. We also need to persist the selection between sessions and page loads.

I'll be using localStorage to store the user's preference and AlpineJS to handle the toggling action. Alpine is a lightweight JS framework that works with your markup and doesn't require a build step.

As well as storing the user's preference we'll need to apply it as early as possible during page rendering to activate their desired mode.

How it Works

Tailwind generates classes that are applied when dark mode is activated
When our page loads we see if the user has set an explicit choice of mode for our site (using the UI control we provide)
If they've asked for dark mode we apply the CSS class
If they have not set a preference, but their implicit preference via their OS is for dark mode we apply the CSS class
Otherwise we'll fall back to the default light mode
When our user makes a specific choice using the on-page UI we'll update the document class and also save their preference in localStorage for subsequent page loads.

UI Control

Here's the code to provide light & dark mode buttons. Alpine uses the x-data property to store the state for our component. x-init runs on setup and syncs our local state with what was previously stored in localStorage.

<div
  x-data="{
      mode: '',
      setColorMode: m => {
          if (m === 'dark') {
              document.documentElement.classList.add('dark')
              localStorage.setItem('colorMode', 'dark')
          } else {
              document.documentElement.classList.remove('dark')
              localStorage.setItem('colorMode', 'light')
          }
      }
  }"

  x-init="() => {
      const m = localStorage.getItem('colorMode');
      if (m !== 'dark' && m !== 'light') return;
      mode = m;
  }"
>
  <button
    @click="mode='light'; setColorMode('light');"
    :class="{'font-bold': mode === 'light', 'font-thin': mode !== 'light' }"
    class="underline px-2 py-1 rounded-md border-white hover:bg-gray-100 dark:hover:bg-gray-800"
    >
    light
  </button>

  <button
    @click="mode = 'dark'; setColorMode('dark');"
    :class="{'bg-gray-700 text-gray-200 border border-solid border-gray-600 font-bold': mode === 'dark', 'font-thin': mode !== 'dark' }"
    class="underline px-2 py-1 rounded-md hover:bg-white dark:hover:bg-gray-800"
    >
    dark
  </button>
</div>

Persisting The Selection

Of course as users browse around your site you don't want them to have to re-apply their choice of colour mode every time they visit a new page. We'll use a bit of JS near the top of our document to reapply their preference as early in the render as possible.

<head>
  <!-- other bits -->
  <link rel="stylesheet" href="css/style.css" type="text/css">
  <script src="detect-mode.js"></script>
</head>

// detect-mode.js
// set initial color scheme

let explicitelyPreferScheme = false
if (window.localStorage) {
    if (localStorage.getItem('colorMode') === 'dark') {
        document.documentElement.classList.add('dark')
        explicitelyPreferScheme = 'dark'
    } else if (localStorage.getItem('colorMode') === 'light') {
        document.documentElement.classList.remove('dark')
        explicitelyPreferScheme = 'light'
    }
}

if (explicitelyPreferScheme !== 'light' && window.matchMedia('(prefers-color-scheme:dark)').matches) {
    document.documentElement.classList.add('dark')
}

This will apply dark mode if our visitor has selected it from the UI control above; or if they have not set any preference but their OS is set to use dark mode.

Live Demo

Test it out here. You can refresh the page and see your preference persist.

This was originally published on my website mikehealy.com.au

Lighter LoDash Builds for Laravel

Mike Healy — Tue, 05 Jan 2021 23:18:56 +0000

Laravel projects often include the LoDash JavaScript utility library. It contains handy utilities, however if you don't need its entire suite you may be serving unnecessary JS to your users that you never run.

LoDash supports custom builds to avoid this problem, and it's fairly easy to modify your Laravel's bootstrap.js file trim down the features you're loading.

Default resources/js/bootstrap.js

window._ = require('lodash'); // 71.1K (gzipped: 24.6K)

Customizing the build

In my case I was only using the throttle and debounce helpers from LoDash. This can be mapped to the window lodash object (typically _) like so:

window._ = require('lodash/core')  // 14K (gzipped: 5.3K)
window._.debounce = require('lodash/debounce')  // 3.5K (gzipped: 1.4K)
window._.throttle = require('lodash/throttle') // 3.7K (gzipped: 1.4K)

My application JS can then call _.debounce() and _.throttle() for those functions with a significant saving to my JS bundle size.

16GB or 32GB RAM for Web Development?

Mike Healy — Tue, 14 Jul 2020 03:11:09 +0000

My 2013 15" MBP will reach the end of its life at some point and I'm looking to replace it with a 16" ARM MBP when they're released.

I do full stack web dev with PHP, and JS/Vue/static site generators on the front end. I also do some visual design, and occasional lightweight video editing (iMovie only).

I'll use the new machine for at least 3 years, and maybe even 5 or 6 years. I'd like to get 32GB of RAM, but it is an expensive upgrade, it's not something I'll add just for the sake of it.

How useful do you think the extra 16GB of RAM will be for this sort of work?

Help: Should a new service worker force a refresh to update a PWA?

Mike Healy — Sat, 04 Jan 2020 23:39:32 +0000

I have a frontend app called Finskore for scoring games of Finska that I want to enable offline.

I'm following Google's PWA guide about service workers and it seems that an updated service worker will only take effect on the following visit. The existing SW runs the current session, but the new version is installed for the next network visit.

My question is, should I try and detect when a new service worker has been installed and force a refresh at that time? The reason being to get the new version of the app for the immediate session.

I was wondering if I could compare cache version names on install and do a window.reload() if they are different?

Thoughts?

How to Build an Image Carousel

Mike Healy — Mon, 25 Nov 2019 06:57:11 +0000

Don't.

Improving Performance for Low-Bandwidth Users with save-data

Mike Healy — Wed, 25 Sep 2019 23:42:08 +0000

Everyone likes a fast website, but some users have connections and data plans that make it especially critical. In some places bandwidth is expensive, and any bytes you don't need to serve can save your users money.

I recently learned about the 'save-data' HTTP header that clients may send to signify that they want a lower-bandwidth experience. The header alone doesn't do much, but it makes their preferences clear to you so you can make your own optimizations.

On mobile Chrome this setting is called 'Lite Mode'. Desktop users can install a browser extension to enable the header. Other browsers likely have their own way of enabling the setting.

Once you've detected this setting you might choose to style elements differently (for example dropping large background images), avoid decorative background video, or perhaps skip custom fonts that might delay rendering and add to the bandwidth costs.

The setting can be detected server-side by looking for a HTTP header (save-data=on) or client side in JS to set a flag for your CSS selectors.

//PHP example
function saveData() {
   return (isset($_SERVER["HTTP_SAVE_DATA"]) && strtolower($_SERVER["HTTP_SAVE_DATA"]) === 'on');
}

//JS example (courtesy of Nooshu)
//add save-data class name to document element for CSS selectors
if ("connection" in navigator) {
    if (navigator.connection.saveData === true) {
        document.documentElement.classList.add('save-data');
    }
}

With the detection in place you can omit non-essential elements to low-bandwidth users. For example, on my WordPress website I've skipped queuing Google custom fonts, and dropped my masthead background image.

// functions.php
if( !saveData() ) {
  wp_enqueue_style( 'fonts', 'https://fonts.googleapis.com/css?family=Open+Sans|Oswald:300,400,600');
}

/*
N.B. in WP it's good practice to prefix functions to avoid naming clashes.
I've skipped that for this example */

Here's my site on mobile Chrome with and without Lite Mode (aka sava-data).

This was a pretty easy change to make for some quick performance gains for low-bandwidth users. The improvements could be even bigger for heavier sites, or if the header was considered during site development too.

(This post was originally published at mikehealy.com.au)