Real talk about The Edge™️

Issue #240.November 16, 2023.2 Minute read.
Bytes

Today’s issue: How the web is getting faster, why microservices aren’t the problem, and how some Netflix engineers became showrunners during the writers’ strike.

Welcome to #240.


Eyeballs logo

The Main Thing

Dobby from Harry Potter dancing

Life is better on the edge

Real talk about The Edge™️

If you’ve been on tech Twitter at all this week, you’ve probably seen multiple debates about the advantages and tradeoffs of different edge computing approaches for SSR apps. The founders of Remix and Vercel all shared their takes, along with other less wealthy/popular engineers that we still pretend to respect.

But what’s the debate? We’ve written past stories about how “the edge” is just fancy marketing speak for “running servers close to your users,” so isn’t it always faster to server render your app as close to your users as possible?

Well, it depends on what you’re trying to build. And we also need to remember that we’re dealing with two different servers here — the application server and the database server.

With that in mind, let’s look at the three main architectural approaches to building SSR applications in JavaScript today.

Origin app server + Origin DB server: Putting your application server and your database server next to each other lets your app go back and forth with the DB (or other services in the same region) without fighting the laws of physics. The downside is that the further away your users are from your origin, the longer each client request is going to take.

Edge app server + Origin DB server: Recently, it’s become popular to host your application server at The Edge™️ (aka the closest server to the end user). This allows you to serve dynamic content to your users without the latency of going back and forth to your origin. That sounds great in theory, but if your edge application has to make frequent trips to the origin for data, it can end up being slower than the origin + origin approach in some cases.

Edge app server + Edge DB server: Companies like Cloudflare, Turso, and Fly are championing this new approach. It’s the best of both worlds, right? Right? It could be for some apps, but the downside is that you have to deal with distributed databases and things like eventual consistency (or as I like to call it “immediate inconsistency”).

Bottom Line: The Edge™️ is great, but it doesn’t give us one silver bullet approach that guarantees the best performance and DX for every scenario. So for now, we still need to evaluate the tradeoffs and make the best choice for the specific app we’re building.

Or, as Jerry Seinfeld once said, “Find the torture you’re comfortable with.”

        

secureframe logo

Our Friends
(With Benefits)

A guy with cash behind his glasses

When you get that new enterprise customer cash

Secureframe makes SOC 2 compliance easy

Getting your application SOC 2 certified will finally let you start landing those big enterprise customers – but it usually takes months of engineering time, and lots of tricky hoops to jump through ☠️.

That’s why thousands of companies let Secureframe handle it.

They’ve automated the entire compliance process for SOC 2 and other security/privacy frameworks like ISO 27001, GDPR, and HIPAA. So now you can get certified in weeks, instead of months.

Plus, their AI-powered platform lets you automate manual tasks, so it’s easy for you to stay compliant in the future.

Set up a free, personalized demo — and they’ll help you get all those fancy security compliance badges on your homepage ASAP.


Spot the Bug logo

Spot the Bug

Sponsored by P0 Security

Their guide on Investigating Google Service Account Key Origins and Usage provides best practices to control access and gain visibility into which identities (human or machine) have excessive and possibly dangerous permissions.

// service-worker.js
const CACHE_NAME = "site-static-v1";
const assetsToCache = ["/", "/index.html", "/css/style.css", "/js/script.js"];

// Install event
self.addEventListener("install", (event) => {
  event.waitUntil(
    caches.open(CACHE_NAME).then((cache) => {
      cache.addAll(assetsToCache);
    })
  );
});

// Fetch event
self.addEventListener("fetch", (event) => {
  event.respondWith(
    caches.match(event.request).then((cacheResponse) => {
      return cacheResponse || fetch(event.request);
    })
  );
});

Cool Bits logo

Cool Bits

  1. Rick Viscomi, a DevRel engineer at Google, wrote about A faster web in 2024. And despite what you hear from the React haters, he shares data about how the web is faster than it’s ever been and how it’ll continue to speed up next year.

  2. Vite 5 just dropped this morning. We’ll dive into it on Monday.

  3. We’re getting closer to releasing query.gg, the official React Query course that we’re making with the RQ core team. Sign up for the email list if you want to get updates and discounts.

  4. Dmitry Non wrote an article called Microservices aren’t the problem. Incompetent people are. Tell us how you really feel, Gilfoyle Dmitry.

  5. react-google-maps is a new (still alpha) React wrapper for the Google Maps JavaScript API that allows you to use a Google Map as a fully controlled reactive component.

  6. James Somers wrote an article for The New Yorker called, A Coder Considers the Waning Days of the Craft. Nothing like a 5,000-word essay about your dying profession to get you hyped up on a Thursday morning. #RiseAndGrind.

  7. Ante Barić wrote about How and why Daily Dev switched from Preact to React.

  8. Alan Norbauer, a JavaScript developer at Netflix, wrote an article called 67 Weird Debugging Tricks Your Browser Doesn’t Want You to Know. Rumor has it that Netflix greenlit this article to be turned into an 8-episode mini-series when they were desperate for content during the writers’ strike.

  9. Loro is a CRDTs library that makes building local-first apps easier.

  10. React Datasheet Grid is an Airtable-like component to create beautiful spreadsheets. This is great news for people like me who have built their entire workflow on Airtable over the past five years and get more than a little nervous every time the company announces another round of layoffs.


Spot the Bug logo

Spot the Bug: Solution

Sponsored by P0 Security

In the original code, the service worker caches the assets on install, but it doesn’t update the cache when the assets change. This means that if you update your CSS or JS, the service worker will still serve the old version.

To fix this we can use the cache.put() method to update the cache when the assets change.

// service-worker.js
const CACHE_NAME = "site-static-v1";
const assetsToCache = ["/", "/index.html", "/css/style.css", "/js/script.js"];

// Install event
self.addEventListener("install", (event) => {
  event.waitUntil(
    caches.open(CACHE_NAME).then((cache) => {
      cache.addAll(assetsToCache);
    })
  );
});

// Fetch event
self.addEventListener("fetch", (event) => {
  event.respondWith(
    caches.match(event.request).then((cacheResponse) => {
      return (
        cacheResponse ||
        fetch(event.request).then((fetchResponse) => {
          return caches.open(CACHE_NAME).then((cache) => {
            cache.put(event.request.url, fetchResponse.clone());
            return fetchResponse;
          });
        })
      );
    })
  );
});

Before you get too confident, just remember, service workers were created to keep you humble (allegedly).