DEV Community: Mat Silva

From JavaScript to Scala

Mat Silva — Fri, 18 Apr 2025 19:24:50 +0000

I was writing C# when Node.js came along. You could run JavaScript on the server now. I was in awe. It wasn’t perfect. But it was freeing and dynamic. I went all in.

Then came React. Its mental model aligned perfectly with mine. It was simply the V in MVC. Declarative and flexible. It just made sense. Those were good times. I felt like I was standing at the beginning and could clearly see the future. I went all in, again.

As JavaScript evolved it initially went where I was hoping it would, but then it blew past to... something else? We seemed to lose our way with error handling. We shoved React SSR Frameworks down everyones throat. & we let TypeScript(a superset of javascript) win over Javascript and now it’s everywhere, too a fault.

How do I know? Well when all of my non JS colleagues keep referring to node or javascript as Typescript... that means it's over.

There are bits about Typescript I really like. I like being able to eliminate statically typed defects. No more guessing at what the data arg is. That has been pretty damn sweet. But everything else? Just tends to get in the way...

Pure ESM, while arguably a better approach to modules adds to the hard edges.

I've tried ejecting from TypeScript and going back to plain JavaScript and pure ESM. But you quickly hit walls trying to tap into the JS ecosystem. Modern JS tooling seems overly dependent on it. You end up having to roll your own everything if you want to eject. You'll eventually find yourself coming back to TypeScript because sadly it is now the least path of resistance.

I'm hopeful for the future of ~~JavaScript~~Typescript, but at present it doesn't quite spark joy for me.

I started looking elsewhere. I picked up Golang. Bought the books. Built the apps. I liked it. And it worked rather well. Cross platform binaries out of the box was the chefs kiss. Maybe Go was it?

Maybe not... I really liked it, but it felt too simple, if that even makes sense. I recognize 'simple' is arguably a good thing. But I wanted more depth. Something that could grow with me. Go felt better, but it didn’t make me want to build just for the sake of building again.

Then, over a year ago, I joined AKA Identity and had to jump into Scala. The architect chose it for AKA's data pipeline. I’d never given Scala much thought before. So at first, I had low expectations. Scala seemed to have a reputation, "Something something about functional purists". I pictured obscure, obfuscated one-liners.

Sieve of Eratosthenes
(n: Int) => (2 to n) |> (r => r.foldLeft(r.toSet)((ps, x) => if (ps(x)) ps -- (x * x to n by x) else ps))
source: 10 scala one liners to impress your friends

As part of my team's book club, we picked up Oderskys' Programming in Scala. I couldn’t put it down. I ended up getting more books. Along the way, I felt excited again. Scala could be powerful without being heavy handed. Expressive without being verbose. I could apply it creatively. Artfully. But only, if I wanted too... Scala for the most part, could be pragmatic and simple.

& I really appreciated that the Scala devs at AKA leaned into writing pragmatic Scala. Had they not, it's entirely possible I would not have ever given Scala a fair shake.

My time so far with Scala, reminds me of those early days with Node. The urge to build, creatively, outside of the box. It’s hard to explain. But it felt good. As I learned from Oderskys' writing and others, my mind adapted to Scala’s mental models. It was like the Tetris pieces were falling into place, at the right angle, and clicking. To say it was satisfying would be an understatement.

So now, I’m thinking about writing this series; From JS to Scala.

If you're a fellow js dev and feel like I did, largely stuck and and a bit unsatisfied, looking for creative freedom. Maybe Scala will do it for you, too.

Fwiw, I am not making a 'die hard' switch to Scala. I'll continue to write in TypeScript, Go, and other languages. Scala hasn't replaced them, it made me better at using them. It opened up my mental model and changed how I think about the problem at hand. It made me a more thoughtful coder.

Heres what I am thinking so far:

Async, Multithreading, Coroutines: As They Should Be
- Compare how Scala and Node.js handle concurrency and CPU-bound tasks.
- Why async in Node.js trips up developers, who inadvertently block the main thread.
- How this compares to Async in Scala: Native multithreading and coroutine support mean true parallelism without blocking the main thread.
Types: Practical and Reliable Typing Without Verbosity/Gymnastics
- Why Scala’s type system feels more natural, less verbose, and more flexible compared to TypeScript.
- Using case classes and sealed traits for structured, type-safe data.
- How type inference reduces boilerplate without sacrificing clarity.
- Compare a simple(at least it should be) implementation of returning [Error, GenericType] in TypeScript vs Scala.
For-Comprehensions: Concise Async Control Flow
- Use for-comprehensions for asynchronous operations and data transformation.
- Replace complex callback chains or async/await patterns without reducing all errors into a single try-catch channel like JavaScript does.
- Real-world examples comparing JS async/await and promise chains to Scala’s for-comprehensions.
Pattern Matching for Control Flow
- How Scala’s pattern matching offers a more intuitive way to manage control flow.
- Demonstrate pattern matching with both simple and complex data types.
- Show how pattern matching can cleanly handle data processing and branching logic compared to typical control flow you'd see in Javascript.
Options and the None Type: No More Null & Undefined Shenanigans
- Compare Scala’s Options approach to TypeScript’s nullable types.
- Highlight the confusion between valid JavaScript and TypeScript's rigidity, where making valid JS work freely often results in weird and inconsistent handling of null, undefined, and other falsey values.
- & How ultimately, Scala’s Option makes handling potential value absence straightforward, eliminating null and undefined entirely.
Writing APIs That Feel Native
- Imagine being able to define a custom operator in TypeScript, like Akka’s ! operator in Scala, to send messages with a simple syntax: myService ! "Hello, World!".
- In TypeScript, achieving this would require writing a custom compiler plugin, and even then, it would be cumbersome to adopt and maintain. In Scala, the ability to express syntax like this is built in. It enables creative expression, to solve the problem at hand.
Pragmatic Scalability: Avoiding Clever Code
- This will show that Scala can be written using simple and pragmatic semantics. Which is important for new comers like myself.
- Discusses the reality that Scala can also enable very obscure, albeit clever, code. & as Odersky says, we should apply this artfully.
- Highlight libraries that promote pragmatic Scala usage, like those by Li Haoyi (e.g., lihaoyi’s libraries).
- Practical examples of balancing expressiveness with readability.
Building and Deploying a Scala App: From Nuts to Soup
- A full example of building, testing, and deploying a Scala application. It can be a lot easier than you'd think.

& I am sure plenty more after I groom my past notes from the books I've read.

** Topic Ideas From Feedback:

What Senior Frontend Developers Actually Care About

Mat Silva — Wed, 26 Mar 2025 14:07:16 +0000

Years ago, I completed a take-home challenge that landed me a senior frontend job at LogDNA. Technology has moved on—Playwright is replacing Cypress, SSR frameworks like Next and Remix surpassed single-page apps—but the core principles haven’t changed. Good principles outlast tech trends.

1. Architecture That Scales

Senior developers build code designed to grow. Scalability isn't just about technical performance or user experience; it also involves internal processes to easily onboard new developers and sustain long-term maintenance:

Clear Structure: Logical separation between UI and backend, clearly shown in a monorepo structure:

  packages/
    ├── ui/                  # Frontend application
    │   ├── src/
    │   │   ├── api-client/  # API client layer
    │   │   ├── form/        # Form components and state
    │   │   ├── layout/      # Layout components
    │   │   ├── translate/   # i18n utilities
    │   │   └── types/       # TypeScript type definitions
    │   └── package.json
    └── server/              # Backend application
        └── package.json

Predictable Typing: Strongly typed systems (e.g., TypeScript) with shared types:

  export interface AlertDetails { message: string; condition: 'HOURLY' | 'DAILY'; recipients: string[]; }

Simplified State Management: Reactive state handling with minimal boilerplate (MobX):

  class FormInputState<T> { values = observable({}); errors = observable({}); }

Flexible Forms: Real-time, robust validation (Joi schemas):

  const alertSchema = { message: Joi.string().required(), recipients: Joi.array().items(Joi.string().email()).required() };

2. Testing as a Priority

Quality code requires thorough testing:

Clear Logic Testing: Straightforward unit tests for components.
Real-world Scenarios: Cypress for end-to-end user behavior.
Inclusive Design Testing: Axe-core for accessibility.
Comprehensive Coverage: Validating both success and error scenarios.

3. Developer Experience

Good developers write readable, maintainable code:

Consistent Formatting: Prettier to streamline readability.
Logical Organization: Components, tests, and styles grouped logically.
IDE Integration: TypeScript catches errors during development.
Clear Documentation: Simple, comprehensive README files.

4. Thoughtful User Experience

Senior developers see what others miss:

Immediate Feedback: Real-time validation with clear interactions:

  form.validateValue('recipients', emails);

Accessibility: Keyboard navigation, ARIA roles, and managed focus.
Transparent States: Clear loading indicators and actionable error messages:

  <button disabled={!form.isValid || loading}>{t('form.save')}</button>

Inclusive Design: UX designed for all users.

5. Internationalization from the Start

Thinking global from day one:

Scalable Translations: Externalize all strings:

  await i18next.init({ fallbackLng: 'en', backend: { loadPath } });

Clear Localization: Maintainable file structures by locale.

6. Performance Matters

Performance is prioritized

Optimized Builds: Fast-loading, minimal bundle sizes.
Maintainable Build Outputs: Cleanly structured artifacts.
React Render Optimizations: Using MobX for precise JSX updates, outperforming React’s native state handling in efficiency and clarity:

  <Observer>{() => <TextInput value={form.values.message} />}</Observer>

7. Built-in Security

Security isn't optional:

Strict Validation: Sanitized inputs with schemas:

  Joi.string().email().required()

HTML Escaping: Preventing XSS by escaping HTML:

  const sanitized = Object.assign({}, request.payload, { message: Hoek.escapeHtml(request.payload.message) });

CORS Protection: Configured secure cross-origin resource sharing:

  cors: { additionalHeaders: ['Access-Control-Allow-Headers'], origin: [CORS_ORIGIN] }

Data Discipline: Discerns what data presents risks.
Resource Handling: Configured secure access policies.

8. Choosing Quality Tools (at the Time)

Quality is in careful selection:

Intentional Choices: Tools aligned with clear goals (e.g., TypeScript, MobX, Tailwind).
Balance and Pragmatism: Effective solutions, minimal complexity.

What This Means

Senior frontend developers aren’t swayed by trends. They adhere to timeless principles:

Maintainability
Scalability
Usability
Reliability
Accessibility
Global readiness
Performance

The Core Idea

Hiring senior developers is about finding those who build on lasting principles. They know it's not just about what to build but how to build it. Solid foundations always matter more than the latest technologies.

JavaScript Lost Its Way With Error Handling

Mat Silva — Mon, 24 Mar 2025 16:54:16 +0000

Reasoning About JavaScript Errors Used to Be Simple

We had a dedicated channel in callbacks. We knew when something went wrong for that function.

fs.readFile('file.txt', (err, data) => {
  if (err) {
    console.error(err);
    return;
  }
  console.log(data);
});

You checked for the error. You dealt with it.

No surprises. No magic.

It wasn’t pretty, because callback hell. But it was clear.

Then Came Async/Await

It looked clean. Linear. Easy to follow. Arguably, it still is.

But we started throwing errors again, to a fault.

Now errors are all in the same channel.

Like this:

fastify.get('/user/:id', async (req, reply) => {
  const user = await getUser(req.params.id);
  if (!user) throw fastify.httpErrors.notFound();
  return user;
});

This seems fine—until you need to do more than one thing.

Suddenly, your catch block becomes a patchwork of if-statements:

fastify.get('/user/:id', async (req, reply) => {
  try {
    const user = await getUser(req.params.id);
    if (!user) throw fastify.httpErrors.notFound();

    const data = await getUserData(user);
    return data;
  } catch (err) {
    if (err.statusCode === 404) {
      req.log.warn(`User not found: ${req.params.id}`);
      return reply.code(404).send({ message: 'User not found' });
    }

    if (err.statusCode === 401) {
      req.log.warn(`Unauthorized access`);
      return reply.code(401).send({ message: 'Unauthorized' });
    }

    req.log.error(err);
    return reply.code(500).send({ message: 'Unexpected error' });
  }
});

You're using catch not just for exceptions, but for expected things:

A user not found
Invalid auth
Bad input

You're forced to reverse-engineer intent from the thrown error.

You lose clarity. You lose control.

Other Languages Seem To Do Better

Go

Go keeps it simple. Errors are values.

data, err := ioutil.ReadFile("file.txt")
if err != nil {
    log.Fatal(err)
}

You deal with the error. Or you don’t. But you don’t ignore it.

Scala

Scala uses types to make the rules clear.

val result: Either[Throwable, String] = Try {
  Files.readString(Path.of("file.txt"))
}.toEither

result match {
  case Left(err)   => println(s"Error: $err")
  case Right(data) => println(s"Success: $data")
}

You must handle both outcomes.

No free passes. No silent failures.

Use Option for missing values.

val maybeValue: Option[String] = Some("Hello")

val result = maybeValue.getOrElse("Default")

No null. No undefined. No guessing.

What JavaScript Could Be

We don’t have to do this:

try {
  const data = await fs.promises.readFile('file.txt');
} catch (err) {
  console.error(err);
}

We could do this:

const [err, data] = await to(fs.promises.readFile('file.txt'));

if (err) {
  console.error('Failed to read file:', err);
  return;
}

console.log('File contents:', data);

It’s clear. It’s honest. It works.

Or we use a result wrapper:

const result = await Result.try(() => fs.promises.readFile('file.txt'));

if (result.isErr) {
  console.error(result.error);
} else {
  console.log(result.value);
}

You know what's expected. You know what blew up.

Want to Write Better Code?

Here are some tools to help with that:

await-to-js — [err, data] pattern
neverthrow — type-safe error handling
oxide.ts — Rust-style Result and Option types for TypeScript

One Last Thing

This is a bit of the old “you made your bed, now lie in it.”
We started throwing everything into a single channel.
We didn’t think it through.

But it’s fixable.

Choose better patterns.
Throw less.
Write what you mean.

Anyone Else Tired of Having SSR Shoved Down Their Throats?

Mat Silva — Wed, 19 Mar 2025 14:42:48 +0000

You see back in the day, deploying a single page app(SPA) or static site was dead simple. We had tools like now, firebase deploy, etc that offered one command deployments for any client side app framework. I loved those tools.

But when I reached for them to build a client side app, their OOTB SPA support was largely, gone?

What the heck happened?

SSR frameworks did. The entire React ecosystem has over rotated. What was once the V in MVC, is now an overly-prescriptive framework that encourages newcomers to 'lock in' to a recommended full-stack framework.

Go look at the react docs today. See for yourself. (as of 4-18-2025).

And note...

The push to full-stack frameworks
No mention of vite as an option to scaffold a react app.
A big green note explainering our misconceptions about these frame-works...

It seems to me that the writing is on the wall

Even react router now leads with the 'framework' mode first. Pushing client side apps further and further into 2nd and 3rd class citizens.

& for that reason, I have my client side react apps pinned on react router 6.30.0. I'm also tempted to fork this version, rip out the server side framework bits and make the client a first class citizen again.

Could someone explain to me why we are acting like frontend teams need full stack platforms just to build and ship client side apps?

& how the heck did we let these platforms convince us they can charge us for bandwidth for our app's static assets? – A commodity that is practically free due to CDN technology.

What is stockholm syndrome for $800?

Maybe I'm just getting old? But while I was wrestling these frameworks, I had a moment where I was like why is this so much harder than it needs to be? Are people really happy with with this for client side only apps?

I just needed to be able to ship a relatively simple client side app, quickly. So I reached for vite to scaffold my react app. Thank you vite for making this dead simple!

But now for deployments... oof. Wow. How did we take so many steps backwards?

Did I really need to reinvent the wheel? I guess so... so I did and it was kinda glorious. I dusted off an ole' nginx hash and cache strategy I wrote about years ago.

& turned it into a CLI called godeploy. It does what I needed:

Generates Nginx configs
Handles hashed assets for proper caching **
Packs everything into a Docker container

Then I made it open source. If you want to host your own frontend using an nginx server that will beat the pants off of any SSR runtime, it's yours to do so.

But I still missed the one-command deploy.

So you bet your sweet buns I built that too.

godeploy deploy

Your app goes live at:

https://your-autogenerated-subdomain.spa.godeploy.app

All too easy. As it should be.

Now this is a hosted service, not open source. But it feels like the old days. One command. Done.

In case you are wondering, I most definitely like Tony Montana right now, getting high on my own supply with GoDeploy.

& As an ROI junky in a past life, I had to throw in my deployment stats in the dashboard.

Just look at those graphs

Anyway no pressure. I'm just shipping what I needed.

https://godeploy.app

https://github.com/matsilva/godeploy

The Tech Shed - Remote Work Space

Mat Silva — Wed, 28 Aug 2019 20:18:12 +0000

Hi I am Mat Silva & I work remotely. I wanted to share some pictures of my work space (what I call the "tech shed").

I am still working on better cable management 😬

When it rains, I really enjoy being able to feel close to it.

Here is a little bit wider of a view...

& every now and then my dogs want to hang with me in here.

UPDATE:
Added some sweet lighting & more art from @geneljumalon

Got a cool setup for your workspace? Share in the comments.

Fetch API gotcha in cypress.io and how to fix it.

Mat Silva — Tue, 27 Aug 2019 17:23:40 +0000

The problem:
When you use the fetch API on the client side, you cannot stub routes in cypress.io because of the lack in support in cypress atm.

This is something I ran into when implementing the graphql apollo-client apollo-link-rest, since it uses the fetch api out of the box.

Here is what I did to fix it:
First I made sure to polyfill the fetch api using whatwg-fetch, but only in development or testing environments, since I don't need it in production builds.

So in my the main entry point to my app index.tsx, I added this near the top.

//**this will get stripped out of production builds by webpack */
//@ts-ignore
if (!PRODUCTION) {
    require('whatwg-fetch'); //for polyfill cypress test 
}

For my webpack.development.js config file, I added this:


plugins: [
    new webpack.DefinePlugin({
        PRODUCTION: JSON.stringify(false),
    }),
],

and in my webpack.production.js config file, I added this:


plugins: [
    new webpack.DefinePlugin({
        PRODUCTION: JSON.stringify(true),
    }),
],

Next I added a new visitWithDelWinFetch command to cypress which will delete the fetch api on the window object.

Cypress.Commands.add('visitWithDelWinFetch', (path, opts = {}) => {
    cy.visit(
        path,
        Object.assign(opts, {
            onBeforeLoad(win) {
                delete win.fetch;
            },
        })
    );
});

This will kick in the fetch polyfill. Now you'll be able to stub routes like you'd expect in cypress.

cy.server();
cy.route('/path/to/api/').as('getApiPath');
cy.visitWithDelWinFetch('/');

And to give credit where it's due, this was largely inspired by this solution in the comments.

Also note that if you don't care about ever using the fetch api in your tests, you could avoid having a separate visit command using this solution paired with the fetch polyfill.

Boost the UX of your React app with hash based content caching.

Mat Silva — Sun, 04 Aug 2019 15:38:44 +0000

What problem are we trying to solve?

Say you have a JavaScript app that gets served up at http://mysite.com/js/myapp.js. A typical performance optimization is to tell the browser to cache myapp.js so that the user doesn't have to re-download the asset every time they use the app. If you practice continuous delivery, the problem you run into is delivering new app updates. If myapp.js is cached, the user won't get the new updates until either a) they clear their cache or b) the max-age expires.

From the google dev docs:

Ideally, you should aim to cache as many responses as possible on the client for the longest possible period, and provide validation tokens for each response to enable efficient revalidation.

What we're going to do in this guide is we're going to come up with a way to cache our application assets for the longest possible time: FOREVER! Well sort of.. we are going to be using a hash based content caching strategy, which the google dev docs mentions it gives you the best of both worlds: client-side caching and quick updates.

Getting started with create-react-app

So to get started, we are going to use good ole create react app to quickly standup a new single page application.

Let's create a new app, create-react-app content-cache

So in a new directory, ~/code, lets run this:

npx create-react-app content-cache
cd content-cache

So now you'll have a new app setup in ~/code/content-cache and you should now be in the content-cache directory.

Now we can run npm run build which will output all the assets for your app in ./build. With these assets now available, let's take a look at serving these with nginx.

nginx + docker = yayyyyyy

Let's go ahead and create a new file, touch ~/code/content-cache/Dockerfile with the following contents:

FROM nginx:1.13-alpine

RUN apk add --no-cache bash curl

COPY nginx/ /

CMD ["/docker-entrypoint.sh", "nginx", "-g", "daemon off;"]

EXPOSE 8080

COPY build/static/ /usr/share/nginx/html/

COPY package.json /

You'll notice we are missing a few things:

The nginx/folder being copied.
The docker-entrypoint.sh script.

Let's go ahead and add those now.

Create a new directory, mkdir -p ~/code/content-cache/nginx/etc/nginx and then create a new file touch ~/code/content-cache/nginx/etc/nginx/nginx.conf.

Then open up the file and copy the following contents into it:

user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    sendfile        on;

    keepalive_timeout  65;

    gzip  on;
    gzip_types text/plain application/xml application/javascript text/css;

    include /etc/nginx/conf.d/*.conf;
}

Most of this is boilerplate nginx config, so I am not going to spend time explaining it, you can learn more from the nginx docs. Just note that we are including /etc/nginx/conf.d/*.conf, which includes the default.conf file, we'll be creating next.

Let's go ahead and create the file, touch ~/code/content-cache/nginx/etc/nginx/conf.d/default.conf and add the following contents to it:

server {
    listen       8080;

    # include the hash based content
    include /etc/nginx/conf.d/app/*.conf;

    location ~ ^/$ {
        # we are serving the app at `/a/`
        return 303 a/;
    }

    # serve other static assets
    location / {
        root   /usr/share/nginx/html;
        index  /index.html;
        try_files $uri /index.html;
        include /etc/nginx/conf.d/app/preload.headers;
    }
}

We are going to be serving the app at /a/, which is a strategy used to make life a bit easier when dealing with reverse proxying to backend APIs that live on the same domain.

So again, make note that we are including /etc/nginx/conf.d/app/*.conf;, which is our hash based content.

Now let's move on to creating a new file touch ~/code/content-cache/nginx/docker-entrypoint.sh where the magic happens.

Paste in the following contents:

#!/usr/bin/env bash

mkdir -p /etc/nginx/conf.d/app
pushd /usr/share/nginx/html/js/ > /dev/null

APP_JS=/app/js/app.js
for js in main.*.*.js
do
    cat  > /etc/nginx/conf.d/app/js.conf <<EOF
location ~* ^/app/js/main.js([.]map)?\$ {
    expires off;
    add_header Cache-Control "no-cache";
    return 303 ${js}\$1;
}
location ~* ^/app/js/(main[.][a-z0-9][a-z0-9]*[.]js(?:[.]map)?)\$ {
    alias   /usr/share/nginx/html/js/\$1;
    expires max;
    add_header Cache-Control "public; immutable";
}
EOF
    APP_JS="/js/${js}"
    break;
done
RUNTIME_JS=/app/js/runtime.js
for js in runtime~main.*.js
do
    cat  > /etc/nginx/conf.d/app/js.conf <<EOF
location ~* ^/app/js/runtime~main.js([.]map)?\$ {
    expires off;
    add_header Cache-Control "no-cache";
    return 303 ${js}\$1;
}
location ~* ^/app/js/(runtime~main[.][a-z0-9][a-z0-9]*[.]js(?:[.]map)?)\$ {
    alias   /usr/share/nginx/html/js/\$1;
    expires max;
    add_header Cache-Control "public; immutable";
}
EOF
    RUNTIME_JS="/js/${js}"
    break;
done
VENDOR_JS=/app/js/vendor.js
for js in 2.*.*.js
do
    cat >> /etc/nginx/conf.d/app/js.conf <<EOF
location ~* ^/app/js/2[.]js([.]map)?\$ {
    expires off;
    add_header Cache-Control "no-cache";
    return 303 ${js}\$1;
}
location ~* ^/app/js/(2[.][a-z0-9][a-z0-9]*[.]js(?:[.]map)?)\$ {
    alias   /usr/share/nginx/html/js/\$1;
    expires max;
    add_header Cache-Control "public; immutable";
}
EOF
    VENDOR_JS="/js/${js}"
    break;
done

cd ../css
APP_CSS=/app/css/main.css
for css in main.*.*.css
do
    cat > /etc/nginx/conf.d/app/css.conf <<EOF
location ~* ^/app/css/main.css([.]map)?\$ {
    expires off;
    add_header Cache-Control "no-cache";
    return 303 ${css}\$1;
}
location ~* ^/app/css/(main[.][a-z0-9][a-z0-9]*[.]css(?:[.]map)?)\$ {
    alias   /usr/share/nginx/html/css/\$1;
    expires max;
    add_header Cache-Control "public; immutable";
}
EOF
    APP_CSS="/css/${css}"
done

cd ..

cat > /etc/nginx/conf.d/app/preload.headers <<EOF
add_header Cache-Control "public; must-revalidate";
add_header Link "<${APP_CSS}>; rel=preload; as=style; type=text/css; nopush";
add_header Link "<${VENDOR_JS}>; rel=preload; as=script; type=text/javascript; nopush";
add_header Link "<${APP_JS}>; rel=preload; as=script; type=text/javascript; nopush";
add_header X-Frame-Options "SAMEORIGIN" always;
EOF

cat > index.html <<EOF
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8"/>
    <meta name="viewport" content="width=device-width, initial-scale=1.0"/>
    <meta http-equiv="X-UA-Compatible" content="ie=edge"/>
    <title>Create React app</title>
    <link href="${APP_CSS}" rel="stylesheet">
</head>
<body>
    <div id="root"></div>
    <script type="text/javascript" src="${VENDOR_JS}"></script>
    <script type="text/javascript" src="${APP_JS}"></script>
    <script type="text/javascript" src="${RUNTIME_JS}"></script>
</body>
</html>
EOF

popd > /dev/null

exec "$@"

Let's go ahead and break this down bit by bit.

mkdir -p /etc/nginx/conf.d/app
pushd /usr/share/nginx/html/js/ > /dev/null

This creates a new directory and uses pushd to cd into the /usr/share/nginx/html/js directory, while redirecting the output to /dev/null so the console doesn't get noisy.

APP_JS=/a/js/app.js
for js in main.*.*.js
do
    cat  > /etc/nginx/conf.d/app/js.conf <<EOF

This is a for loop, which iterates over the javascript files matching main.*.*.js, which is the pattern for our hashed content files. It then concatenates the location blocks into a file /etc/nginx/conf.d/app/js.conf.

location ~* ^/a/js/main.js([.]map)?\$ {
    expires off;
    add_header Cache-Control "no-cache";
    return 303 ${js}\$1;
}

We also are redirecting any requests to /a/js/main.js to the matching hash based filed.

location ~* ^/a/js/(main[.][a-z0-9][a-z0-9]*[.]js(?:[.]map)?)\$ {

Also notice we are matching .map files so that we can load source map files as well.

    alias   /usr/share/nginx/html/js/\$1;

Then we are caching those hash based files to the MAX!

    expires max;
    add_header Cache-Control "public; immutable";
}
EOF

We then store the hashed asset file in APP_JS so we can use that later in the script.

    APP_JS="/js/${js}"
    break;
done

The next three for loops do the same as above, but for the different asset files. The runtime files runtime~main.*.js, the vendor files 2.*.*.js, and the css files main.*.*.css.

Next we set our preload.headers.

cat > /etc/nginx/conf.d/app/preload.headers <<EOF
add_header Cache-Control "public; must-revalidate";
add_header Link "<${APP_CSS}>; rel=preload; as=style; type=text/css; nopush";
add_header Link "<${VENDOR_JS}>; rel=preload; as=script; type=text/javascript; nopush";
add_header Link "<${APP_JS}>; rel=preload; as=script; type=text/javascript; nopush";
add_header X-Frame-Options "SAMEORIGIN" always;
EOF

This tells the browser to preload these assets and store these files in the http cache. We specify nopush so that the server knows we only want to preload it for now.

We then dynamically create our index.html file:

cat > index.html <<EOF
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8"/>
    <meta name="viewport" content="width=device-width, initial-scale=1.0"/>
    <meta http-equiv="X-UA-Compatible" content="ie=edge"/>
    <title>Create React app</title>
    <link href="${APP_CSS}" rel="stylesheet">
</head>
<body>
    <div id="root"></div>
    <script type="text/javascript" src="${VENDOR_JS}"></script>

We use the APP_JS variable to set the src for our js file. We also do the same for the other asset files.

    <script type="text/javascript" src="${APP_JS}"></script>
    <script type="text/javascript" src="${RUNTIME_JS}"></script>
</body>
</html>
EOF

Then we change back to the original directory with popd > /dev/null and then execute any args passed to this script exec "$@". That's important otherwise the args after the "/docker-entrypoint.sh" will not work in our Dockerfile command: CMD ["/docker-entrypoint.sh", "nginx", "-g", "daemon off;"].

Let's see it all in action

We're going to build and run the Docker container.

In ~/code/content-cache, run:

chmod +x ./nginx/docker-entrypoint.sh - make the script executable.
docker build -t nginx/test . - this builds the image.
docker run --name="nginx-test-app" -p 8080:8080 nginx/test - this runs the docker container.

Now that your app is running, head to http://localhost:8080. Open up the network tab in your dev tools and refresh the page. You should see the JavaScript and CSS assets should now be getting cached. It should look something like this:

Looking good! Now let's do another build just to make sure it is working as intended. Kill the current docker container by pressing ctr + c and then running docker rm nginx-test-app.

Now run npm run build && docker build -t nginx/test . then docker run --name="nginx-test-app" -p 8080:8080 nginx/test, open up http://localhost:8080 and checkout the network tab to confirm that the asset files are from the latest build.

🤘Now we're talking! At this point now, we have the best of both worlds setup: Max content caching and quick updates when a new version of our app is deployed.

Feel free to use this technique and modify to fit your own needs. The link to the repo is below.

Resources:

github repo

Credits:

@connolly_s - showed me the light with this strategy 🤣