DEV Community: smapiot

Hyper-Scale Activated! Ship Your Own FaaS 🤖

Florian Rappl — Fri, 18 Oct 2024 12:34:36 +0000

In the past decade I've done a lot of work on distributed web applications. In that area you definitely require processes that work implicitly - fully decoupled, with autonomy for individual teams and modules.

The key question quite often is:

How awesome would it be to just extend your application at runtime without any downtime whatsoever?!

In this article I want to look at how we can extend a Node server using Express.js to act like a FaaS provider (such as AWS Lambda or Azure Functions).

Prerequisites

To follow this article you'll need the following:

Node.js with npm installed (I recommend version 22 or higher - we'll use fetch in Node, which is available since version 18)
A code editor
If you want to clone the sample project you'll need to have git installed (but you can download it as a ZIP from GitHub)
Access to the Piral Cloud Feed Service - you can use it for free using a Microsoft or GitHub account

Architecture

Before we start to write some code let's look at the anticipated architecture:

Using the Piral Cloud Feed Service we get access to a dynamic service / module registry, which we can leverage to load a list of modules, evaluate them directly from their URLs, and then use them to populate a list of (sub-)routers.

The routers are necessary to extend the default router middleware. Let's see the whole thing in action. We start by writing the server.

Writing the Server

As server we use a pretty standard and lightweight Express.js server. It can be created by running the following commands in a new directory.

We first initialize a new npm project:

npm init -y

Now we install the required dependency:

npm i express

We add a new file (index.js) with the following content:

const express = require("express");

const port = 3000;
const app = express();

app.get("/", (req, res) => {
  res.send("Hello world!");
});

app.listen(port, () => {
  console.log(`Running at http://localhost:${port}`);
});

And we finally run the application:

node index.js

Go to localhost:3000 in the browser of your choice and see that everything is running as it should:

Great! But there is a bit more to it for making it truly dynamic...

Making the Server Dynamic

So what we are after is to run modules that we can just publish whenever we feel the need for it. The first thing to look for is to avoid having routing issues.

To prevent different modules for occupying the same route we will actually namespace the routes by their module names. In Express.js this also allows us to use dynamic Router objects, which are bound to their module names.

In code this can be done like that:

const routers = {};

app.use("/:namespace", (req, res, next) => {
  const { namespace } = req.params;
  const router = routers[namespace];

  if (router) {
    return router(req, res, next);
  }

  return next();
});

We introduce a middleware that is sensitive to a namespace parameter. In a productive setup we might want to constraint this a bit further, e.g., /api/:namespace or /apps/:namespace, to avoid clashes between in-built functionality and the modules.

The job of the middleware is to use the retrieved namespace value by looking at all available sub-routers. If a sub-router is matched we will use the sub-router as follow-up middleware. Otherwise, we continue with the next middleware. Usually, the next middleware would be the "not-found-route" from Express.js.

The question to answer now is how to populate the routers object. How can we obtain these sub-routers?

What we can do is to introduce a function to obtain the information from a discovery service. This service gets us all the relevant pieces of information - we then only need to load / run the referenced modules.

The necessary code to built something like that is:

const feed = "https://feed.piral.cloud/api/v1/pilet/express-demo";

function makeId(item) {
  return `${item.name}@${item.version}`;
}

async function loadPlugins() {
  console.log("Loading plugins ...");
  const res = await fetch(feed);
  const { items } = await res.json();

  for (const item of items) {
    const id = makeId(item);
    console.log(`Integrating plugin "${id}" ...`);
    await installPlugin(item);
    console.log(`Integrated plugin "${id}"!`);
  }

  watchPlugins();
}

loadPlugins();

What are we doing here?

We want to start loading the plugins / sub-routers as fast as possible. So we immediately run the loadPlugins function. Ideally we use the top-level await here; if it's not available (or if we want to save a bit of startup time) we just call it as shown.
The loadPlugins fetches the information from the discovery service.
Once the information is fetched we go over the contained items array. Each item is treated like the meta information of a plugin - so we just call installPlugin to use the found meta information.
Finally we also want to react when something changes - so the loadPlugins part concludes by watching for changes using the watchPlugins function.

Important Note
If you want to follow this on your own then replace https://feed.piral.cloud/api/v1/pilet/express-demo with your own discovery feed URL. Using the Piral Cloud Feed Service you can see the URL on the feed overview page.

Let's look at the installPlugin first:

const current = [];

async function installPlugin(item) {
  const { name, link } = item;
  const router = express.Router();
  const { setup } = await loadModule(link);
  typeof setup === "function" && setup(router);
  routers[name] = router;
  current.push({ id: makeId(item), name });
}

Doesn't look too complicated, does it? What's happening here?

We decompose the item - but we are only interested in the name and link (module reference / URL) of the module.
We create a new Express.js Router instance (the "sub-router").
We load the respective module - it should get us a function called setup (now this is a design choice; you could either name it differently, make it a default export, or export a Router instance directly...
If we really obtained a setup function we call it with the Router instance. This can now be modified properly.
Finally, the created router is assigned to the routers object and the current array is extended with the proper entry.

As you might have guessed the current array is for book-keeping purposes. It allows us to easily patch / change the routers in case of changes. For this, we'll need to look at the watchPlugins function:

const WebSocket = require("ws");

const changeEventTypes = ["add-pilet", "update-pilet", "remove-pilet"];

function watchPlugins() {
  console.log("Watching plugins ...");
  const ws = new WebSocket(feed.replace("http", "ws"));

  ws.on("error", console.error);

  ws.on("message", async (data) => {
    const msg = JSON.parse(Buffer.from(data).toString("utf8"));

    if (changeEventTypes.includes(msg.type)) {
      const res = await fetch(feed);
      const { items } = await res.json();
      const removeItems = current.filter(
        ({ id }) => !items.some((n) => makeId(n) === id)
      );
      const addItems = items.filter(
        (item) => !current.some(({ id }) => id === makeId(item))
      );

      for (const item of removeItems) {
        await uninstallPlugin(item);
      }

      for (const item of addItems) {
        await installPlugin(item);
      }
    }
  });
}

For this code to run we rely on the ws library. So we'll need to install it first:

npm i ws

With ws active we can have a look at what the code does:

We define some events we want to listen to. The provided events are send via the WebSocket channel in case the contained modules change.
Once a message is received we transform it (from raw bytes to a JSON object) and check if the type matches one of the events defined in (1).
We could now use the information from the event, but some events (e.g., update-pilet) don't tell us what changed. In such cases we could be in a problematic zone. So we follow the safe route and just re-load all the modules.
Finally, we need to compare the current information from the discovery service vs the stored / previous information. For the changed (removed, updated) modules we remove them using the uninstallPlugin. All the ones that are not yet instantiated we add them using the installPlugin function.

The uninstallPlugin looks as follows:

async function uninstallPlugin(item) {
  delete routers[item.name];
  current.splice(current.indexOf(item));
}

That was easy, right? But so far we avoided the most complicated topic. How are we evaluating those modules?

Evaluating Modules from URLs

In the browser you can always evaluate ESMs - they are coming from an URL by default. The same is true in runtimes such as Deno. But in Node.js this is not possible. So should we give up?

As it turns out evaluating URLs is actually not so difficult. We need 2 things:

Code to use the vm module. We need to rely on the SourceTextModule to create modules on the fly.
The experimental flag --experimental-vm-modules for running Node. This way, the SourceTextModule is available at runtime.

Using those two ways we can add the following code to our server:

const vm = require("vm");

async function linkModule(url, ctx) {
  const res = await fetch(url);
  const content = await res.text();
  const mod = new vm.SourceTextModule(content);
  mod.context = ctx;
  await mod.link((specifier) => {
    const newUrl = new URL(specifier, url);
    return linkModule(newUrl.href, ctx);
  });
  await mod.evaluate();
  return mod;
}

async function loadModule(url) {
  const ctx = vm.createContext();

  try {
    const res = await linkModule(url, ctx);
    return res.namespace;
  } catch (ex) {
    console.warn(`Failed to evaluate "${url}":`, ex);
    return {};
  }
}

Finally, we have everything together and can just run the server with the flag:

node --experimental-vm-modules index.js

We should see output like this in the console:

Loading plugins ...
Running at http://localhost:3000
Integrating plugin "app1@2.0.0" ...
Integrated plugin "app1@2.0.0"!
Integrating plugin "app2@1.0.4" ...
(node:23052) ExperimentalWarning: VM Modules is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
Integrated plugin "app2@1.0.4"!
Integrating plugin "app3@1.0.0" ...
Integrated plugin "app3@1.0.0"!
Watching plugins ...

Here, we are already including a couple of modules (referred to as plugins). Let's see what we can do here - how we can write, deploy, and update them.

Example Functions

One Module

The first example is a really simple one; just a single function to return a constant string:

export function setup(router) {
  router.get("/foo", (req, res) => {
    res.send("Hello from app1 v2: /foo");
  });
}

Importantly, we initialize a new project and define the package.json like this:

{
  "name": "app1",
  "version": "1.0.0",
  "module": "index.js",
  "scripts": {
    "deploy": "publish-microfrontend --url https://feed.piral.cloud/api/v1/pilet/express-demo --interactive"
  },
  "devDependencies": {
    "publish-microfrontend": "^1.6.2"
  }
}

The publish-microfrontend script is used to deploy the module. This little script just packages the current project and invokes a POST against the provided discovery service URL. The --interactive flag then allows us to dynamically log into the discovery service to deploy our function.

We'll see how this process looks in a second. Let's look at another example.

Two Modules

While publishing the package with a single module works as expected the question is: Does it also work with more modules? The answer is yes.

Pretty much the same definition in the package.json:

{
  "name": "app2",
  "version": "1.0.0",
  "module": "lib/index.js",
  "scripts": {
    "deploy": "publish-microfrontend --url https://feed.dev.piral.cloud/api/v1/pilet/express-demo --interactive"
  },
  "devDependencies": {
    "publish-microfrontend": "^1.6.2"
  }
}

But now lib/index.js is different:

import { compute } from './other.js';

export function setup(router) {
  router.get("/compute", (req, res) => {
    const { a, b } = req.query;
    const c = compute(+a, +b);

    if (!isNaN(c)) {
      return res.status(200).send(`${c}`);
    }

    return res.status(400).send(`Only numbers allowed.`);
  });
}

Not only is this a bit more logic - it also uses a function from another module located at lib/other.js:

export function compute(a, b) {
  if (typeof a === "number" && typeof b === "number") {
    return (a + b) * (a - b);
  }

  return NaN;
}

As you might have guessed our ESM URL loader just works as it should. No questions asked. Great!

We won't answer the burning question: Can it do three modules? I guess we know the answer, but if you want to find out get active now!

In the meantime we go already to the complex case of having the modules written in TypeScript - and including some dependencies.

TypeScript Modules with Dependencies

Consider the code at src/index.ts:

import cors from 'cors';
import type { Router } from "express-serve-static-core";

export function setup(router: Router) {
  router.use(cors());

  router.get("/", (req, res) => {
    res.status(404).send(`NOT FOUND.`);
  });
}

Here we are using types and dependencies. This won't work - we don't do any dependency resolution and we don't transpile TypeScript. So should we be worried? Not at all!

Let's bundle it using esbuild:

esbuild --outdir=dist src/index.ts --bundle --platform=node --format=esm

Even better - we can just extend the package.json to take care of this in the deploy task:

{
  "name": "app3",
  "version": "1.0.0",
  "module": "dist/index.js",
  "scripts": {
    "build": "esbuild --outdir=dist src/index.ts --bundle --platform=node --format=esm",
    "deploy": "npm run build && publish-microfrontend --url https://feed.dev.piral.cloud/api/v1/pilet/express-demo --interactive"
  },
  "devDependencies": {
    "@types/cors": "^2.8.17",
    "@types/express": "^5.0.0",
    "esbuild": "^0.24.0",
    "publish-microfrontend": "^1.6.2"
  },
  "dependencies": {
    "cors": "^2.8.5"
  }
}

This way, we can just write anything - bundle it using esbuild and ship it with publish-microfrontend.

Now let's step back a bit and see how we actually deploy the modules:

Deployment

Maybe let's see first how it looks in the discovery service when we deployed all of our modules:

As already mentioned for deploying such a module we can use the available publish-microfrontend npm package:

npx publish-microfrontend --url <your-discovery-service-url> --api-key <your-key>

In cases such as the ones above we might swap the --api-key with an --interactive flow, where we need to use the browser for obtaining a user token instead.

npx publish-microfrontend --url <your-discovery-service-url> --interactive

Let's see how this process looks in real life:

In the end having such a powerful service registry between our server and the respective modules is not only clean, but also useful for flexibility reasons.

Advanced Dynamics

We already saw that the dynamics with respect to partial rollbacks are in place from the beginning. In general, the service registry's portal gives us the ability to control every bit of the delivery process:

The version selector in particular is quite useful. Besides the possibility of making rollbacks, we can also do feature flags, A/B testing, blue-green deployments, or canary releases.

Quite powerful stuff...

This allows us, e.g., to have multiple instances of our Express.js server, where each instance might get a different set of modules. Sounds crazy (how can this be useful?!) but if you don't consider these instances equal (i.e., meant for scaling), but rather as different sites (e.g., one for US, one for EU etc.) then backend behavior might be different - at least in some areas.

Beforehand, that was a lot of overhead. You had to produce countless variations of the same server - now you can just have one and have the different behavior qualified through the loaded modules.

Conclusion

In this article you've seen how you can easily extend your Express.js server into a FaaS platform allowing you to add, update, and remove endpoints on the fly.

Of course, the provided sample is rather simplistic and does not solve some of the issues including advanced isolation, memory footprint (unload and restrictions of modules), local module development using an emulator, and many others. But it's a very convenient start - showing what's possible with just a few lines of code.

Check out the sample code at github.com/piral-samples/piral-cloud-express-plugins-demo.

MDX with Translations 🐠

Florian Rappl — Tue, 03 Sep 2024 15:13:11 +0000

In recent years the need for some easy yet flexible format for simple static content has grown. Originally, HTML was meant for that - but let's be honest: it is neither simple, nor flexible. There have been plenty replacement proposals - as pretty much every CMS comes with its own dialect.

One good contender for static content that can be read and rendered nicely is Markdown. However, it has quite a bit of shortcomings. Most notably, Markdown is not fully specified - leading to multiple dialects that exist. Furthermore, many necessary things are only available in form of non-standard extensions. Finally, using custom components within Markdown is not possible.

This is where MDX comes into play. It's essentially a hybrid of JSX / React and a well-specified dialect of Markdown. Essentially, this allows writing texts that are as simple as plain Markdown, as well as creating complex components as you might have done in full JSX.

Website Structure

We build upon the structure set up in our recently published article faster pages with React and our original blog post from 2019. In this structure we have all the pages placed in their path-relative order using React for each page:

Now there are two things that we want to take care of:

Improve the content writing (and reading) for each employee at smapiot
Simplify translations; right now the structure requires duplicating pages (placing them with different / translated content in the "de" and "en" folders).

For the former we want to leverage MDX - for the latter we need to come up with a solution that allows us to have a flat structure.

Integrating MDX

Bringing MDX into the solution is actually quite straight forward. The @mdx-js/mdx package contains everything to compile and work with MDX files. However, as we are already using a bundler (Vite), we can just rely on the specific plugin that exists for that bundler.

npm i @mdx-js/rollup --save-dev

Why are we installing a package called rollup if our bundler is Vite? It turns out, that Vite is actually just a build-tool - for the actual bundling two other things are used:

esbuild to bundle/process anything in the third-party packages (as well as use it, e.g., on the config file)
rollup to bundle/process the user code

Hence the rollup plugin - which is all we need.

The integration into our vite.config.mjs file looks like this:

import codegen from 'vite-plugin-codegen';
import mdx from '@mdx-js/rollup';
import { resolve } from 'path';

export default {
  build: {
    assetsInlineLimit: 0,
  },
  resolve: {
    alias: {
      '@': resolve(__dirname, 'src'),
    },
  },
  plugins: [
    codegen(),
    mdx(),
  ],
};

Note that we are not providing any options right now. It just works!

So what can we do here? Consider one of our previous pages, the legal disclaimer (who doesn't love legal pages?!):

import * as React from 'react';
import { Page } from '@smapiot/components/lib/basic/Page';

export const meta = {
  title: 'Legal Disclaimer',
  legal: 'Legal Disclaimer',
};

const title = 'smapiot - Legal Disclaimer';

export default () => (
  <Page title={title}>
    <section className="container">
      <h1>Legal Disclaimer</h1>
      <h3>Liability for Contents</h3>
      <p>
        The contents of our pages have been compiled with the greatest care. However, we cannot guarantee for accuracy,
        completeness or topicality of the contents. As service providers, we are liable for own contents of these
        websites according to sec. 7, paragraph 1 German Telemedia Act (TMG). However, according to sec. 8 to 10 German
        Telemedia Act (TMG), service providers are not obligated to permanently monitor submitted or stored information
        or to search for evidences that indicate illegal activities. Legal obligations to removing information or to
        blocking the use of information remain unchallenged. In this case, liability is only possible at the time of
        knowledge about a specific violation of law. Illegal contents will be removed immediately at the time we get
        knowledge of them.
      </p>
      <h3>Liability for Links</h3>
      <p>
        Our web pages include links to external third party websites. We have no influence on the contents of those
        external websites, therefore we cannot guarantee for those contents. Providers or administrators of linked
        websites are always responsible for their own contents. The linked websites had been checked for possible
        violations of law at the time of the establishment of the link. Illegal contents were not detected at the time
        of the linking. A permanent monitoring of the contents of linked websites cannot be imposed without reasonable
        indications that there has been a violation of law. Illegal links will be removed immediately at the time we get
        knowledge of them.
      </p>
      <h3>Copyright</h3>
      <p>
        Contents and compilations published on these websites by the providers are subject to German copyright laws.
        Reproduction, editing, distribution as well as the use of any kind outside the scope of the copyright law
        require a written permission of the author or originator. Downloads and copies of these websites are permitted
        for private use only. The commercial use of our contents without permission of the originator is prohibited.
        Copyright laws of third parties are respected as long as the contents on these websites do not originate from
        the provider. Contributions of third parties on this site are indicated as such. However, if you notice any
        violations of copyright law, please inform us. Such contents will be removed immediately.
      </p>
    </section>
  </Page>
);

This isn't too bad! What we can now do is to rename it from Disclaimer.tsx to Disclaimer.mdx and change its content to become:

export const meta = {
  title: 'Legal Disclaimer',
  legal: 'Legal Disclaimer',
};

<section className="container">
  # Legal Disclaimer

  ### Liability for Contents

  The contents of our pages have been compiled with the greatest care. However, we cannot guarantee for accuracy, completeness or topicality of the contents. As service providers, we are liable for own contents of these websites according to sec. 7, paragraph 1 German Telemedia Act (TMG). However, according to sec. 8 to 10 German Telemedia Act (TMG), service providers are not obligated to permanently monitor submitted or stored information or to search for evidences that indicate illegal activities. Legal obligations to removing information or to blocking the use of information remain unchallenged. In this case, liability is only possible at the time of knowledge about a specific violation of law. Illegal contents will be removed immediately at the time we get knowledge of them.

  ### Liability for Links

  Our web pages include links to external third party websites. We have no influence on the contents of those external websites, therefore we cannot guarantee for those contents. Providers or administrators of linked websites are always responsible for their own contents. The linked websites had been checked for possible violations of law at the time of the establishment of the link. Illegal contents were not detected at the time of the linking. A permanent monitoring of the contents of linked websites cannot be imposed without reasonable indications that there has been a violation of law. Illegal links will be removed immediately at the time we get knowledge of them.

  ### Copyright

  Contents and compilations published on these websites by the providers are subject to German copyright laws. Reproduction, editing, distribution as well as the use of any kind outside the scope of the copyright law require a written permission of the author or originator. Downloads and copies of these websites are permitted for private use only. The commercial use of our contents without permission of the originator is prohibited. Copyright laws of third parties are respected as long as the contents on these websites do not originate from the provider. Contributions of third parties on this site are indicated as such. However, if you notice any violations of copyright law, please inform us. Such contents will be removed immediately.
</section>

Much easier to read! Note that unnecessary imports such as react could be removed, while the boilerplate wrapper component Page will now be automatically inserted.

But there was a second thing we needed, right? What about improvements for the localization / page structure?

Let's see what we can do here!

Providing Translations

What if we would just put the localization strings all in a little sidecar? For instance, for a file like Disclaimer.mdx we'd also have a file Disclaimer.yml. In this file we could place translations according to the languages.

The whole structure could then look like this:

Where an individual file, e.g., for Disclaimer.yml could be written as:

de:
  content$: |
    # Haftungsausschluss

    ### Haftung für Inhalte

    Die Inhalte unserer Seiten wurden mit größter Sorgfalt erstellt. Für die Richtigkeit, Vollständigkeit und Aktualität der Inhalte können wir jedoch keine Gewähr übernehmen. Als Diensteanbieter sind wir gemäß § 7 Abs.1 TMG für eigene Inhalte auf diesen Seiten nach den allgemeinen Gesetzen verantwortlich. Nach §§ 8 bis 10 TMG sind wir als Diensteanbieter jedoch nicht verpflichtet, übermittelte oder gespeicherte fremde Informationen zu überwachen oder nach Umständen zu forschen, die auf eine rechtswidrige Tätigkeit hinweisen. Verpflichtungen zur Entfernung oder Sperrung der Nutzung von Informationen nach den allgemeinen Gesetzen bleiben hiervon unberührt. Eine diesbezügliche Haftung ist jedoch erst ab dem Zeitpunkt der Kenntnis einer konkreten Rechtsverletzung möglich. Bei Bekanntwerden von entsprechenden Rechtsverletzungen werden wir diese Inhalte umgehend entfernen.

    ### Haftung für Links

    Unser Angebot enthält Links zu externen Webseiten Dritter, auf deren Inhalte wir keinen Einfluss haben. Deshalb können wir für diese fremden Inhalte auch keine Gewähr übernehmen. Für die Inhalte der verlinkten Seiten ist stets der jeweilige Anbieter oder Betreiber der Seiten verantwortlich. Die verlinkten Seiten wurden zum Zeitpunkt der Verlinkung auf mögliche Rechtsverstöße überprüft. Rechtswidrige Inhalte waren zum Zeitpunkt der Verlinkung nicht erkennbar. Eine permanente inhaltliche Kontrolle der verlinkten Seiten ist jedoch ohne konkrete Anhaltspunkte einer Rechtsverletzung nicht zumutbar. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Links umgehend entfernen.

    ### Urheberrecht

    Die durch die Seitenbetreiber erstellten Inhalte und Werke auf diesen Seiten unterliegen dem deutschen Urheberrecht. Die Vervielfältigung, Bearbeitung, Verbreitung und jede Art der Verwertung außerhalb der Grenzen des Urheberrechtes bedürfen der schriftlichen Zustimmung des jeweiligen Autors bzw. Erstellers. Downloads und Kopien dieser Seite sind nur für den privaten, nicht kommerziellen Gebrauch gestattet. Soweit die Inhalte auf dieser Seite nicht vom Betreiber erstellt wurden, werden die Urheberrechte Dritter beachtet. Insbesondere werden Inhalte Dritter als solche gekennzeichnet. Sollten Sie trotzdem auf eine Urheberrechtsverletzung aufmerksam werden, bitten wir um einen entsprechenden Hinweis. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Inhalte umgehend entfernen.
en:
  content$: |
    # Legal Disclaimer

    ### Liability for Contents

    The contents of our pages have been compiled with the greatest care. However, we cannot guarantee for accuracy, completeness or topicality of the contents. As service providers, we are liable for own contents of these websites according to sec. 7, paragraph 1 German Telemedia Act (TMG). However, according to sec. 8 to 10 German Telemedia Act (TMG), service providers are not obligated to permanently monitor submitted or stored information or to search for evidences that indicate illegal activities. Legal obligations to removing information or to blocking the use of information remain unchallenged. In this case, liability is only possible at the time of knowledge about a specific violation of law. Illegal contents will be removed immediately at the time we get knowledge of them.

    ### Liability for Links

    Our web pages include links to external third party websites. We have no influence on the contents of those external websites, therefore we cannot guarantee for those contents. Providers or administrators of linked websites are always responsible for their own contents. The linked websites had been checked for possible violations of law at the time of the establishment of the link. Illegal contents were not detected at the time of the linking. A permanent monitoring of the contents of linked websites cannot be imposed without reasonable indications that there has been a violation of law. Illegal links will be removed immediately at the time we get knowledge of them.

    ### Copyright

    Contents and compilations published on these websites by the providers are subject to German copyright laws. Reproduction, editing, distribution as well as the use of any kind outside the scope of the copyright law require a written permission of the author or originator. Downloads and copies of these websites are permitted for private use only. The commercial use of our contents without permission of the originator is prohibited. Copyright laws of third parties are respected as long as the contents on these websites do not originate from the provider. Contributions of third parties on this site are indicated as such. However, if you notice any violations of copyright law, please inform us. Such contents will be removed immediately.

For this file a set of conventions exist:

The top-level keys must be valid languages (right now only de and en)
The keys can be nested, i.e., objects / arrays are allowed
When a key ends with a $ sign it will be interpreted as Markdown (specifically, MDX)

How does the MDX file look with such a sidecar file?

export const meta = {
  title: 'Legal Disclaimer',
  legal: 'Legal Disclaimer',
};

<section className="container">
  {locale.content$}
</section>

Now this looks appealing!

For integrating the localization we still need to do something. See the use of locale in the code above. But how does locale enter the landscape in the file? After all, we don't see it!

Turns out we can manipulate the generated code by MDX. Let's configure the tool a bit by adding a custom plugin to the recmaPlugins option. This allows us to have full control over the generated abstract syntax tree (AST), which is then used to generate the actual code representing the MDX file.

import codegen from 'vite-plugin-codegen';
import mdx from '@mdx-js/rollup';
import { resolve } from 'path';
import localize from './src/tools/localize.mjs';

export default {
  build: {
    assetsInlineLimit: 0,
  },
  resolve: {
    alias: {
      '@': resolve(__dirname, 'src'),
    },
  },
  plugins: [
    codegen(),
    mdx({
      recmaPlugins: [localize],
    }),
  ],
};

The imported localize function is the actual plugin - which just yields another function - the so-called transformer. The transformer is responsible for manipulating the AST.

The transform function in the next snippet receives the AST and the virtual file (i.e., it's name, content, ...) of the MDX file that is currently being handled.

Let's see the code before we go over what it does:

import { compileSync } from '@mdx-js/mdx';
import { loadLocale } from './localization.mjs';

function fromMarkdown(content) {
  let result = {};
  compileSync(content, {
    development: false,
    recmaPlugins: [
      () => (ast) => {
        const [, fn] = ast.body;
        result = {
          type: 'CallExpression',
          optional: false,
          callee: {
            ...fn,
            id: null,
          },
          arguments: [
            {
              type: 'ObjectExpression',
              properties: [],
            },
          ],
        };
      },
    ],
  });

  return result;
}

function getExpression(content, key) {
  switch (typeof content) {
    case 'object':
      if (Array.isArray(content)) {
        return {
          type: 'ArrayExpression',
          elements: content.map((item, i) => getExpression(item, `${i}`)),
        };
      }

      return {
        type: 'ObjectExpression',
        properties: Object.entries(content).map(([name, value]) => ({
          type: 'Property',
          key: {
            type: 'Identifier',
            name,
          },
          value: getExpression(value, name),
          kind: 'init',
        })),
      };
    case 'number':
    case 'boolean':
      return {
        type: 'Literal',
        value: content,
      };
    case 'string':
      if (key.endsWith('$')) {
        // uses potentially markdown
        return fromMarkdown(content);
      }

      return {
        type: 'Literal',
        value: content,
      };
    case 'undefined':
    default:
      return {
        type: 'Literal',
        value: null,
      };
  }
}

async function transform(ast, vfile) {
  const language = process.env.WEBSITE_LOCALE || 'en';

  const source = vfile.history[0];
  const locale = await loadLocale(source, language);

  const idx = ast.body.findLastIndex((m) => m.type === 'ImportDeclaration');
  const imprt = ast.body.find((node) => node.type === 'ImportDeclaration' && node.source.value === 'react/jsx-runtime');

  const requiredImports = [
    ['_jsx', 'jsx'],
    ['_jsxs', 'jsxs'],
    ['_Fragment', 'Fragment'],
  ];

  for (const requiredImport of requiredImports) {
    const [alias, original] = requiredImport;

    if (!imprt.specifiers.find((node) => node.type === 'ImportSpecifier' && node.imported.name === original)) {
      imprt.specifiers.push({
        type: 'ImportSpecifier',
        imported: {
          type: 'Identifier',
          name: original,
        },
        local: {
          type: 'Identifier',
          name: alias,
        },
      });
    }
  }

  ast.body.splice(idx + 1, 0, {
    type: 'VariableDeclaration',
    kind: 'const',
    declarations: [
      {
        type: 'VariableDeclarator',
        id: {
          type: 'Identifier',
          name: 'locale',
        },
        init: getExpression(locale, language),
      },
    ],
  });
}

const plugin = () => transform;

export default plugin;

Looks more complicated than it needs to be! In the end, it all boils down to changing the AST to

obtain the locale for the document
insert potentially missing named imports (to fully support the generated Markdown / content, if any) into the react/jsx-runtime import
insert the locale declaration - first thing after the imports (this way you can use locale pretty much everywhere in the document
initialize the locale variable to be the object we know; with exception of Markdown strings (suffixed with $): these are transformed into an IIFE keeping the original MDX code

A good way to see what we are doing can be observed by using the MDX playground.

As you can see the compiled code is a bit strange, but can be mapped nicely to our original MDX file.

In contrast, the view that we are actually most interested about is the stage before the code is in that compiled state. It's the "esast" view in the playground (i.e., the AST of the ESTree stage).

What we want to achieve with our plugin is that we manipulate the start. Unfortunately, directly in MDX code we'd need to use an export for that, but by manipulating the AST directly we actually don't need it.

To obtain the locale variable / object we the loadLocale function from a dedicated module.

This module does:

Read and parse the local / file specific translations
Obtain the language-specific translations of the local file
Read and parse the global translations
Obtain the language-specific translations of the global file
Merge with local translations being regarded higher

For obtaining the language-specific translations we choose a base translation (in our case en) and "walk" through the object. The current language (let's say de) then either overrides the base translation or just uses the snippet obtained from the base translation.

You can think of this process as a deep merge with the base translation being the original.

import { readFile } from 'fs/promises';
import { resolve } from 'path';
import { parse } from 'yaml';

async function getLocalization(path) {
  try {
    const content = await readFile(path, 'utf8');
    return parse(content);
  } catch (e) {
    console.error('Error reading YAML file:', e);
    return {};
  }
}

function mergeLocale(result, baseLocale, newLocale) {
  if (!newLocale) {
    Object.assign(result, baseLocale);
  } else {
    Object.entries(baseLocale).forEach(([name, value]) => {
      const c = newLocale[name];

      if (typeof value === 'object') {
        mergeLocale((result[name] = {}), value, c || {});
      } else if (typeof c === 'string' || c) {
        result[name] = c;
      } else {
        result[name] = value;
      }
    });
  }

  return result;
}

function getLocale(locales, lang) {
  const baseLocale = locales.en || {};

  if (lang !== 'en' && lang in locales) {
    const newLocale = locales[lang] || {};
    return mergeLocale({}, baseLocale, newLocale);
  }

  return baseLocale;
}

export async function loadLocale(source, language) {
  if (source.endsWith('.mdx')) {
    const globalFn = resolve(import.meta.dirname, '..', 'global.yml');
    const targetFn = source.replace('.mdx', '.yml');

    const globals = await getLocalization(globalFn);
    const locales = await getLocalization(targetFn);

    return {
      ...getLocale(globals, language),
      ...getLocale(locales, language),
      language,
    };
  }

  return { language };
}

The global translations are placed in the folder above the pages. The name of the file is global.yml.

For the global.yml we only have some very common translation terms stored. An example:

de:
  germany: Deutschland
en:
  germany: Germany

Being able to just change a single file when new translations come (or just changing the structure in one place independent of language changes) is a big deal. For us this was quite important and the new structure reflects that.

Conclusion

With the new approach the pages are much easier to write than beforehand. Also, since we now have a static translation system in place we do not need to duplicate the pages or come up with some complicated system for intermediate components. It's all already done at compile-time in the given structure.

Faster Pages with React ✨

Florian Rappl — Fri, 30 Aug 2024 08:17:31 +0000

Photo by Mathew Schwartz on Unsplash

This is the story of our homepage make over to reach a solid lighthouse score. If you want to read how we made the homepage in the first place then have a look at our blog post from 2019.

Many of the things I write about here can be seen in the Fast Pages with React article.

The Origins

Our homepage started off as a React SPA. Why? It was 2019 and the UI designer created the components all in React. Plus, it was a super smooth experience that was actually quite acceptable.

However, while some may argue that a SPA is not good for SEO this was not the reason why we wanted to have a pre-rendered page. SEO seemed actually fine, but some more simple crawlers did not find all the information as it was hidden behind some JavaScript.

So what can we do here? Well, we can just render everything at build-time using an static-site generation (SSG) approach.

Going into SSG

We did not want to change the overall content or engine behind the page. After all, the DX was great and we thought that reusability of the components is more important than migrating to the latest SSG framework.

After the build (back then using the Parcel v1 bundler) was done, we had a post-build process that took the generated index.html and went through all the detected pages. As our routing is declarative (we already generated the routes from the file system paths) finding the pages was easy.

For each page we ran simple script that does the following things:

Teach Node.js how ESM works (esm module)
Allow using TypeScript via ts-node (our source is using TypeScript)
Add some globals like document or localStorage
Register some additional extensions, e.g., for resolving images as modules in Node.js (these images should resolve to the already generated images from the bundler)
Evaluate the page - using renderToString
Replace the app's content container with the pre-rendered page
Save the HTML of the modified app in a new file that matches the path of the page

In code this worked as follows:



const { readFileSync, writeFileSync, mkdirSync } = require('fs');
const { basename, dirname, resolve } = require('path');

require = require('esm')(module);

require('ts-node').register({
  compilerOptions: {
    module: 'commonjs',
    target: 'es6',
    jsx: 'react',
    importHelpers: true,
    moduleResolution: 'node',
  },
  transpileOnly: true,
});

global.XMLHttpRequest = class {};
global.XDomainRequest = class {};
global.localStorage = {
  getItem() {
    return undefined;
  },
  setItem() {},
};
global.document = {
  title: 'sample',
  querySelector() {
    return {
      getAttribute() {
        return '';
      },
    };
  },
};

const React = require('react');
const { MemoryRouter } = require('react-router');
const { renderToString } = require('react-dom/server');

React.lazy = () => () => React.createElement('div', undefined, 'Loading ...');
React.Suspense = ({ children }) => React.createElement(React.Fragment, undefined, children);
React.useLayoutEffect = () => {};

function setupExtensions(files) {
  ['.png', '.svg', '.jpg', '.jpeg', '.mp4', '.mp3', '.woff', '.tiff', '.tif', '.xml'].forEach(extension => {
    require.extensions[extension] = (module, file) => {
      const parts = basename(file).split('.');
      const ext = parts.pop();
      const front = parts.join('.');
      const ref = files.filter(m => m.startsWith(front) && m.endsWith(ext)).pop() || '';
      module.exports = '/' + ref;
    };
  });

  require.extensions['.codegen'] = (module, file) => {
    const content = readFileSync(file, 'utf8');
    module._compile(content, file);
    const code = module.exports();
    module._compile(code, file);
  };
}

function renderApp(source, target, dist) {
  const sourceModule = require(source);
  const route = (sourceModule.meta.route || target).substring(1);
  const Page = sourceModule.default;
  const Layout = require('../../scripts/layout').default;
  const element = React.createElement(
    MemoryRouter,
    undefined,
    React.createElement(Layout, undefined, React.createElement(Page)),
  );
  return {
    content: renderToString(element),
    outPath: resolve(dist, route, 'index.html'),
  };
}

function makePage(outPath, html, content) {
  const outDir = dirname(outPath);
  const file = html.replace(/<div id="app">(.*)<\/div>/, `<div id="app">${content}</div>`);

  mkdirSync(outDir, {
    recursive: true,
  });

  writeFileSync(outPath, file, 'utf8');
}

process.on('message', msg => {
  const { source, target, files, html, dist } = msg;
  setupExtensions(files);

  setTimeout(() => {
    const { content, outPath } = renderApp(source, target, dist);
    makePage(outPath, html, content);

    process.send({
      content,
    });
  }, 100);
});

The whole process is used as the given module is called from a forked process. So each page is generated in an isolated process.

The following diagram illustrates this process.

What did we win so far? We have a pre-rendered page that works already and transforms to a SPA. Nice. But not enough for us.

Modernizing the Stack

I already described the process as "was". Parcel v1 has not been updated in quite a while and is - from today's point of view - quite slow. It also does not support some modern concepts and should be retired for good.

As a replacement we've chosen Vite. This is a suitable replacement as it comes with a super fast development server and a very well optimized release build.

Also, since we are using codegen for the route retrieval we can still keep using it for Vite.

After all, the whole configuration for Vite to allow the transition is shown below:



import codegen from 'vite-plugin-codegen';
import { resolve } from 'path';

export default {
  build: {
    assetsInlineLimit: 0,
  },
  resolve: {
    alias: {
      '@': resolve(__dirname, 'src'),
    },
  },
  plugins: [codegen()],
};

To avoid Vite's original behavior of inlining smaller assets (which would lead to problems in our SSG behavior) we set the assetsInlineLimit to 0.

One thing we also improved when making the transition from Parcel v1 to Vite is that we introduced path aliases. With the configuration above we can write import '@/foo/bar' instead of going explicitly via the relative path to src/foo/bar. This makes modules more flexible and easier to maintain.

Previously, we used a bit of tools (esm, ts-node, ...) to actually make the SSG happen. With the new setup it was time to reduce the amount of tools and replace them all with esbuild.

The updated code of the SSG kernel module therefore changed a bit, too:



const { writeFile, readFile, mkdir } = require('fs/promises');
const { dirname, resolve, basename, relative } = require('path');
const { createContext, runInContext } = require('vm');
const { compile } = require('./compile');

const React = require('react');
const ReactRouter = require('react-router');
const ReactRouterDom = require('react-router-dom');
const { renderToString } = require('react-dom/server');

React.lazy = () => () => React.createElement('div', undefined, 'Loading ...');
React.Suspense = ({ children }) => React.createElement(React.Fragment, undefined, children);
React.useLayoutEffect = () => {};
React.useEffect = () => {};

async function renderApp(source, target, language, files, dist) {
  const result = await compile({
    dist,
    files,
    target,
    platform: 'node',
    stdin: {
      contents: `
        import { MemoryRouter } from "react-router";
        import Page, { meta } from "./${basename(source)}";
        import Layout from "${relative(dirname(source), resolve(__dirname, '../../layouts/default'))}";

        const page = (
          <MemoryRouter>
            <Layout language="${language}">
              <Page />
            </Layout>
          </MemoryRouter>
        );

        export { page, meta };
      `,
      sourcefile: resolve(dirname(source), 'temp-page.jsx'),
      resolveDir: dirname(source),
      loader: 'jsx',
    },
  });
  const module = {
    exports: {},
  };
  const ctx = createContext({
    exports: module.exports,
    require(name) {
      switch (name) {
        case 'react':
          return React;
        case 'react-router':
          return ReactRouter;
        case 'react-router-dom':
          return ReactRouterDom;
        default:
          console.error('Cannot require', name);
          return undefined;
      }
    },
    setTimeout() {},
    setInterval() {},
    React,
    module,
    XMLHttpRequest: class {},
    XDomainRequest: class {},
    localStorage: {
      getItem() {
        return undefined;
      },
      setItem() {},
    },
    document: {
      title: 'sample',
      querySelector() {
        return {
          getAttribute() {
            return '';
          },
        };
      },
    },
  });
  const code = result.outputFiles.find((m) => m.path.endsWith('.js')).text;

  runInContext(code, ctx);
  const { page, meta } = module.exports;

  return {
    content: renderToString(page),
    meta,
  };
}

async function makeFile(outPath, content) {
  const outDir = dirname(outPath);

  await mkdir(outDir, {
    recursive: true,
  });

  await writeFile(outPath, content, 'utf8');
}

function makePage(outPath, meta, html, content) {
  return makeFile(outPath, html.replace(/<div id="app">.*?<\/div>/s, `<div id="app">${content}</div>`);
}

process.on('message', (msg) => {
  const { source, target, files, language, html, dist } = msg;

  setTimeout(async () => {
    const { content, replacements, meta } = await renderApp(source, target, language, files, dist, html);
    const route = (meta.route || target).substring(1);
    const outPath = resolve(dist, route, 'index.html');
    await makePage(outPath, meta, html, content);

    process.send({
      done: true,
      outPath,
      replacements,
    });
  }, 100);
});

While the overall flow has remained the same, we now convert the page with some imports (e.g., MemoryRouter) to a plain JavaScript script using the CommonJS module system. Therefore, the evaluation with the Node.js vm module does not require esm or ts-node any more. Everything has been taken care of by esbuild.

In the code above the actual esbuild usage is hidden in the compile function, so let's see how we set it up:



const { build } = require('esbuild');
const { codegenPlugin } = require('esbuild-codegen-plugin');
const { resolve, basename } = require('path');

function compile(opts) {
  const { dist, target, stdin, files, platform, entryPoints } = opts;
  const isBrowser = platform === 'browser';
  return build({
    stdin,
    entryPoints,
    outdir: resolve(dist, target.substring(1)),
    write: false,
    bundle: true,
    splitting: isBrowser,
    minify: isBrowser,
    format: !isBrowser ? 'cjs' : 'esm',
    platform,
    loader: {
      '.jpg': 'file',
      '.png': 'file',
      '.svg': 'file',
      '.avif': 'file',
      '.webp': 'file',
    },
    alias: {
      '@': resolve(__dirname, '../..'),
    },
    external: ['react', 'react-router', 'react-router-dom', 'react-dom', 'react-dom/client'],
    plugins: [
      codegenPlugin(),
      {
        name: 'dynamic-assets',
        setup(build) {
          build.onResolve({ filter: /.*/ }, (args) => {
            const name = basename(args.path);
            const idx = name.lastIndexOf('.');
            const front = name.substring(0, idx);
            const ext = name.substring(idx);
            const prefix = front + '-';
            const file = files.find((m) => m.startsWith(prefix) && m.endsWith(ext));

            if (file) {
              return {
                path: file,
                namespace: 'dynamic-asset',
              };
            }

            return undefined;
          });

          build.onLoad({ namespace: 'dynamic-asset', filter: /.*/ }, (args) => {
            const path = `/assets/${args.path}`;
            return {
              contents: `export default ${JSON.stringify(path)};`,
              loader: 'js',
            };
          });
        },
      },
    ],
  });
}

exports.compile = compile;

Quite straight forward. The few things to note are:

Again, the usage of codegen is superb is there is literally a plugin for each bundler. So we can just use the codegen plugin for esbuild and we are covered here.
The dynamic asset plugin that has been defined above looks within the files if the name and extension fits; if it does it will use the already generated one from Vite.
We can reuse the compile function not only for Node.js (the SSG part), but also for compiling some JS functions that run in the browser.

Especially the last point can be crucial. Right now this setup really moves the dynamic part (a SPA) to a fully static one. But we still have some interactive parts in there... So fully hydrating this thing - as we did beforehand - may not be good enough.

But even with this more modern setup one thing was still from 2019: the overall performance.

Lighthouse Issues

In 2019 we still got a great Lighthouse score, but now it's mediocre at best. Lighthouse got a lot more pushy - especially regarding hydration scenarios as we have here.

The score summary is:

Category	Desktop	Mobile
Score	70	50
Best Practices	81	79
First Contentful Paint	0.4 s	1.7s
Largest Contentful Paint	1.6 s	8.4s
Total Blocking Time	0 ms	20ms
Cumulative Layout Shift	1.828	1.899
Speed Index	0.7s	2.1s

There are some findings that seem rather optional, but nevertheless could be implemented rather quickly (or not at all):

Easy: No CSP header (as this is just served as static content we could embed it easily in the HTML as meta tag)
Tedious: On mobile some images are served with a lower resolution (presumably going into the picture tag with different source elements to return the "right" resolution would fit)
Impossible: Deprecated API used (unload handler; use pagehide event instead - actually we don't use this: the problem is coming/injected from a Chrome extension)

Naturally, the question is why the score is so low - and what we can do about it. Notably, we have a CLS (Cumulative Layout Shift) and a quite large LCP (Largest Contentful Paint).

Improvements

The first thing to do is to lower the amount of work that the JS engine has to do. For this we needed to rethink our hydration strategy. The standard one from a React SPA is to hydrate everything. But this comes with a lot of overhead and a quite slow start.

A much better approach would be to include an island architecture style here. Instead of hydrating everything in the beginning, we only hydrate parts - and only hydrate these parts when we need them (e.g., when they become visible).

How can we do that? Time for magic.

Let's consider the following code:



const Testimonials: React.FC = () => (
  <>
    <div className="container">
      <h1>Testimonials</h1>
    </div>
    <div className="quote-carousel">
      <TestimonialsSlides />
    </div>
  </>
);

This is the testimonials part of the homepage. Everything should be static - except the TestimonialsSlides. This is a Carousel with some content. Everything is defined in React.

What if we could just tell the system to hydrate it? Let's imagine we rewrite the code to look like this:



const Testimonials: React.FC = () => (
  <>
    <div className="container">
      <h1>Testimonials</h1>
    </div>
    <div className="quote-carousel" data-hydrate={TestimonialsSlides}>
      <TestimonialsSlides />
    </div>
  </>
);

The only thing we changed is that we added a data-hydrate attribute. Granted, this should be a string - but (surprise) we won't use the attribute anyway. We will actually change the attribute value at build-time.

The architecture that we have in mind works as follows:

The build-time change in the SSG kernel module is an addition for the replacements:



const { createHash } = require('crypto');

async function getUniqueName(path) {
  const fn = basename(path);
  const name = fn.substring(0, fn.lastIndexOf('.'));
  const content = await readFile(path);
  const value = createHash('sha1').update(content);
  const hash = value.digest('hex').substring(0, 6);
  return `${name}.${hash}`;
}

const matcher = /"data-(hydrate|render|load)":\s+(\w+)[,\s]/g;
const replacements = [];

while (true) {
  const match = matcher.exec(code);

  if (!match) {
    break;
  }

  const lookup = match[0];
  const kind = match[1];
  const componentName = match[2];
  const pos = code.indexOf(`var ${componentName}`);
  const idx = code.lastIndexOf('\n// ', pos) + 4;
  const src = code.substring(idx, code.indexOf('\n', idx));
  const entry = resolve(__dirname, '../../..', src);
  const name = await getUniqueName(entry);
  replacements.push({
    lookup,
    entry,
    name,
    value: `"data-${kind}": "/assets/${name}.js",`,
  });
}

for (const { lookup, value } of replacements) {
  code = code.replace(lookup, value);
}

Nice! With this change we have a replacement of the attributes during the build process. We also identify the replacements to use them later on in one joint build process (such that they produce common chunks):



const { writeFile } = require('fs/promises');
const { basename, resolve } = require('path');
const { compile } = require('./compile');

process.on('message', (msg) => {
  const { replacements, dist, files, target } = msg;

  setTimeout(async () => {
    const result = await compile({
      dist,
      files,
      target,
      platform: 'browser',
      entryPoints: replacements.map((m) => ({ in: m.entry, out: m.name })),
    });

    for (const file of result.outputFiles) {
      const name = basename(file.path);
      const content = file.text;
      await writeFile(resolve(dist, target.substring(1), name), content, 'utf8');
    }

    process.send({
      done: true,
    });
  }, 100);
});

The only thing missing is a replacement for the SPA script. The replacement should be able to work with the data-hydrate attribute, which tells the website to hydrate a container with a specific file:



function integrate() {
  function getProps(element: Element) {
    try {
      return JSON.parse(element.getAttribute('data-props'));
    } catch {
      return {};
    }
  }

  function load(fn: string) {
    const react = import('react');
    const reactDom = import('react-dom/client');
    const mod = import(fn);
    return Promise.all([react, reactDom, mod]);
  }

  document.querySelectorAll('*[data-hydrate]').forEach((element) => {
    const fn = element.getAttribute('data-hydrate');
    const observer = new IntersectionObserver((entries) => {
      entries.forEach((entry) => {
        if (entry.isIntersecting) {
          observer.disconnect();
          load(fn).then(([{ createElement }, { hydrateRoot }, m]) => {
            requestAnimationFrame(() => hydrateRoot(element, createElement(m.default, getProps(element))));
          });
        }
      });
    });

    observer.observe(element);
  });

  document.querySelectorAll('*[data-load]').forEach((element) => {
    const fn = element.getAttribute('data-load');
    load(fn).then(([{ createElement }, { hydrateRoot }, m]) => {
      requestIdleCallback(() => hydrateRoot(element, createElement(m.default, getProps(element))));
    });
  });

  document.querySelectorAll('*[data-render]').forEach((element) => {
    const fn = element.getAttribute('data-render');
    load(fn).then(([{ createElement }, { createRoot }, m]) => {
      createRoot(element).render(createElement(m.default, getProps(element)));
    });
  });
}

if (document.readyState === 'loading') {
  document.addEventListener('DOMContentLoaded', integrate);
} else {
  integrate();
}

That is pretty much it! The great thing is that this script is so small that it can be inlined. Since we also know when / if we need replacements we'd only inline the script when we would need it (i.e., when we might hydrate).

Finally, we externalized react (and others), but we did not specify a replacement. As esbuild produces esm files those externals are placed as standard imports such as:



import * as React from 'react';

We would run into problems if such a thing is evaluated in the browser. The solution is to introduce an importmap in our page:



<script type="importmap">
{
  "imports": {
    "react": "https://esm.sh/react@18.3.1",
    "react-dom": "https://esm.sh/react-dom@18.3.1",
    "react-dom/client": "https://esm.sh/react-dom@18.3.1/client"
  }
}
</script>

Note that the importmap is lazyly loaded anyway. So it will perform optimally out of the box.

With everything in place we can look again at the lighthouse score.

The score summary is:

Category	Desktop	Mobile
Score	78	65
Best Practices	81	79
First Contentful Paint	0.6 s	4.3s
Largest Contentful Paint	1.3 s	9.4s
Total Blocking Time	0 ms	10ms
Cumulative Layout Shift	0	0
Speed Index	0.6s	4.3s

While the score is already much better the LCP and overall speed index actually got worse. The reason the score is better is most notably that the CLS is now 0, which is great.

So where did we go wrong?

Final Touches

While the SPA transition hurt our score, it did not hurt as much as badly hydrated components. One of these components is the main carousel, which is shown immediately.

It turns out the carousel component was only made for SPAs. It dynamically computes the width and position of its slides based on the given content. The following diagram shows its working:

In short we have a container that gets the dimensions of the component. Inside the container we use a content element that has the width of the container multiplied by the number of slides + 2. We add two as we also introduce duplicates for the first and last slide. This way, we can have the experience of a real carousel. From the last slide you can keep on swiping right to get to the first slide and vice versa. Essentially, this allows you to keep scrolling in one direction.

What can we do to improve the code here?

Instead of relying on the runtime to set style properties we return a pre-computed style object. This way, we only change dynamic properties when a scrol operation starts.

Originally, the code had a function like:



const updateOffset = () => {
  const c = container.current?.parentElement;

  if (c) {
    const o = offset.current;
    let transform = 'translateX(0)';
    let transition = 'none';

    if (state.desired !== state.active) {
      const dist = Math.abs(state.active - state.desired);
      const pref = Math.sign(o || 0);
      const dir = (dist > length / 2 ? 1 : -1) * Math.sign(state.desired - state.active);
      const shift = (100 * (pref || dir)) / (length + 2);
      transition = smooth;
      transform = `translateX(${shift}%)`;
    } else if (!isNaN(o)) {
      if (o !== 0) {
        transform = `translateX(${o}px)`;
      } else {
        transition = elastic;
      }
    }

    c.style.transform = transform;
    c.style.transition = transition;
    c.style.left = `-${(state.active + 1) * 100}%`;
  }
};

Now we move to:



const updateOffset = () => {
  const c = container.current;

  if (c) {
    const o = offset.current;
    let transform = 'translateX(0)';
    let transition = 'none';

    if (state.desired !== state.active) {
      const shift = getShift(o, state.active, state.desired, length + 2);
      transition = smooth;
      transform = `translateX(${shift}%)`;
    } else if (!isNaN(o)) {
      if (o !== 0) {
        transform = `translateX(${o}px)`;
      } else {
        transition = elastic;
      }
    }

    c.style.transform = transform;
    c.style.transition = transition;
  }
};

The new getShift function is also much improved:



function getShift(o: number, active: number, desired: number, total: number) {
  if (!o) {
    const end = total - 3;

    if (!desired && active === end) {
      o = -1;
    } else if (desired === end && !active) {
      o = 1;
    }
  }

  if (o) {
    const pref = Math.sign(o);
    return (100 * pref) / total;
  } else {
    const diff = active - desired;
    return (100 * diff) / total;
  }
}

This results in a better UX while also improving the story for SSG / SSR.

Besides the work on the carousel component we also optimized the images and spend some time on content cleanup. Nothing dramatic - just little wins here and there.

The score summary is:

Category	Desktop	Mobile
Score	99	87
Best Practices	78	75
First Contentful Paint	0.6 s	2.6s
Largest Contentful Paint	0.8 s	3.4s
Total Blocking Time	0 ms	10ms
Cumulative Layout Shift	0.009	0
Speed Index	0.6s	2.6s

This is it! Wonderful that such a "little" change in a single component can have such a drastic outcome. But in the end it's all about the details.

While every metric now looks good the best practices got a bit worse. Why? Because we added a small video in form of a YouTube embed (iframe) into the homepage. As YouTube brings quite some cookies and other things Lighthouse is not really happy with the third-party content. So we can actually ignore this.

As wanted to be in the 90s rating this is certainly a success and as desired.

Conclusion

Overall, we kept the codebase stable and just gave the whole source code a bit of a makeover. This was sufficient to reach the next level of DX and performance.

As next step we'll modernize some of our content and re-introduce the SPA transition by hijacking internal links; loading an HTML fragment during a page transition. We'll potentially also replace the importmap with an integrated bundle, using Preact in compat mode as a replacement.

Announcing Micro Frontends Conference 2024

Florian Rappl — Wed, 12 Jun 2024 15:37:29 +0000

We are excited to announce our upcoming conference for the Micro Frontends community, taking place on June 17th, 2024. This free event is open to anyone interested in the latest developments in this exciting field.

As one of the most anticipated virtual events of the year, we've secured an impressive lineup of expert speakers who are at the forefront of Micro Frontends innovation. Attendees can expect to hear from some of the most renowned names in the industry, who will be sharing their expertise and insights into the latest advancements in Micro Frontends.

👉 conference.microfrontends.cloud

Like last year we will have some raffles with prizes after each session. Unlike last year we'll have two tracks - to double the fun. Join next Monday!

Here's a sneak peek of the scintillating topics we'll be covering:

🌟 The Perfect Micro Frontends Platform
🎭 Micro Frontends Unmasked: Opportunities, Challenges, and Rational Alternatives
🛠️ The Tractor Store 2.0: The TodoMVC for Micro Frontends
🚀 Hitchhiker's Guide to Dependency Management in Micro Frontends
⚡ Moving at the Speed of Thought
💡 The Problems Micro Frontends Won't Solve That No One Wants to Talk About
🔄 Module Federation in 2024: Beyond Webpack
🎶 Painless Micro Frontend Orchestration with Picard
🤔 The Hidden Challenges of Runtime Integrated Micro Frontends
🌐 Domain-Driven Design in Micro Frontend: Hexagon World
🛤️ Migrating from Monolithic to Future-Proof Micro Frontends
↔️ From React to Angular and Back: Cross-Framework Testing in Micro Frontends
📱 Micro Frontends for Mobile
🏗️ From Monolith to Micro Frontend

Audience

Our conference aims to provide a platform for professionals, enthusiasts, and experts alike to come together and share their experiences, knowledge, and insights into Micro Frontends. Whether you're a seasoned professional or just starting your journey into this field, this conference is an excellent opportunity to learn, connect, and expand your horizons.

This year's conference will be entirely virtual for you, but we'll also have some of the speakers on-site - gathering to some nice open exchange of ideas and perspectives. In general the conference being virtual gives you the flexibility and convenience to participate from anywhere in the world. Also, with no registration fee, the event is accessible to everyone who is interested, making it an excellent opportunity to connect with like-minded individuals from around the globe.

The conference will cover a range of topics, including best practices for implementing Micro Frontends, the latest trends and technologies in the field, and the challenges faced by professionals working in this area. Attendees can expect to learn about everything from testing strategies and modularization to user interface design, dependency sharing and performance optimization.

👉 conference.microfrontends.cloud

Speakers

Michael Geers

A frontend aficionado since his teenage years, Michael Geers is known for his expertise in design systems and web performance. As the author of 'Micro Frontends in Action', he's a go-to source for navigating the complexities of frontend development.

🎤 Talk: "The Tractor Store 2.0: The TodoMVC for Micro Frontends"

Dmitriy Shekhovtsov

Dmitriy is a trailblazer in the world of web technologies, with a stellar track record of contributions to projects like Angular, Angular CLI, TypeScript, Nx, and Rspack. As the founder of Valor Software, Dmitriy is dedicated to empowering the tech community through his innovative open-source libraries, boasting over 140 million downloads.

🎤 Talk: "Moving at the Speed of Thought"

Cathrin Möller

Cathrin brings a wealth of experience to the table as a full-stack developer at TNG Technology Consulting since 2014. With a passion for programming and a focus on software architecture, test automation, and user experience, Cathrin is well-versed in navigating the complexities of modern development projects.

🎤 Talk: "The Hidden Challenges of Runtime Integrated Micro Frontends"

Juan Carlos

With over a decade immersed in software engineering, Juan's journey through front-end development and platform team leadership has been nothing short of remarkable. His expertise in agile methodologies, clean coding practices, and architectural innovation has significantly advanced the maintainability and scalability of codebases across various projects.

🎤 Talk: "From Monolith to Micro Frontend"

Florian Rappl

Dr. Florian Rappl, a solution architect hailing from Germany, is renowned for his expertise in creating scalable distributed web applications. With a specialization in micro frontend solutions, Florian is the author of the acclaimed book 'The Art of Micro Frontends' and conducts workshops for companies worldwide. As a long-time Microsoft MVP in the development tools area, Florian brings a wealth of knowledge and experience to the table.

🎤 Talk: "Painless Micro Frontend Orchestration with Picard"

Mo Javad

Mo is the Head of Mobile at Theodo UK, where he spearheads the creation of cross-platform mobile applications in React Native. With a background in full-stack development and a passion for MobileDevOps, Mo is at the forefront of pushing the boundaries of mobile development. He's also an active member of the React Native community, organizing the React Native London meetup and contributing to open-source projects like Expo and Tamagui.

🎤 Talk: "Micro Frontends for Mobile"

Daniel Ostrovsky

Daniel is a web development expert and teams manager with over two decades of experience in the industry. As the organizer of 'NG-Heroes' meetup and a volunteer at Tech-Career, Daniel is passionate about fostering professional careers in Israel's high-tech sector.

🎤 Talk: "From React to Angular and Back: Cross-Framework Testing in Micro Frontends"

Shelly Goldblit

Shelly is an enthusiastic software engineer with over 25 years of experience in software development, engineering management, and process improvement. With a passion for TDD and clean code, Shelly is dedicated to driving innovation and excellence in software development.

🎤 Talk: "From React to Angular and Back: Cross-Framework Testing in Micro Frontends"

Zackary Jackson

Zackary is a principal engineer and a core maintainer of Webpack, renowned for his expertise in distributed software self-formation and orchestration at runtime. As the creator of Module Federation, Zackary specializes in Javascript Architecture and is passionate about scaling distributed frontend applications.

🎤 Talk: "Module Federation in 2024: Beyond Webpack"

David Serrano

With over 12 years of experience as a professional UI/UX developer, David is dedicated to crafting easy-to-use, snappy user interfaces. Currently, he's focused on creating tooling and frameworks to streamline frontend development for companies, making him a leading figure in the industry.

🎤 Talk: "Migrating from Monolithic to Future-Proof Micro Frontends"

Jennifer Wadella

Described as a force of nature, Jennifer is a visionary leader with a stellar track record in management excellence and frontend engineering. With a keen eye on current development trends, Jennifer is dedicated to driving teams towards success in today's dynamic landscape.

🎤 Talk: "The Problems Micro Frontends Won't Solve That No One Wants to Talk About"

Stefan Bley

Stefan is a software architect at ZEISS Digital Innovation in Berlin, with a rich background in Angular projects across various industries. An avid experimenter with new technologies, Stefan is passionate about sharing his knowledge through speaking engagements and community events.

🎤 Talk: "Hitchhiker's Guide to Dependency Management in Micro Frontends"

Lucas Braeschke

Lucas embarked on his journey as a Full Stack Developer at ZEISS Digital Innovation in Dresden, where his passion for TypeScript and Angular truly flourished. With a knack for web development since his early school days, Lucas brings a wealth of experience to the table.

🎤 Talk: "Hitchhiker's Guide to Dependency Management in Micro Frontends"

Luca Mezzalira

Luca is a principal solutions architect at AWS, an international speaker, and a seasoned author with over 20 years of experience in mastering software architectures. From frontend development to cloud solutions, Luca's expertise spans the entire spectrum, allowing him to provide tailored solutions for any job context.

🎤 Talk: "The Perfect Micro Frontends Platform"

Manfred Steyer

Manfred is a renowned trainer, consultant, and programming architect specializing in Angular. As a Google Developer Expert (GDE) and Trusted Collaborator in the Angular team, Manfred brings a wealth of expertise to the table. With a penchant for sharing knowledge, he regularly contributes to leading publications such as O'Reilly, the German Java Magazine, and windows.developer, and is a sought-after speaker at conferences worldwide.

🎤 Talk: "Micro Frontends Unmasked: Opportunities, Challenges, and Rational Alternatives"

Ildar Sharafeev

Ildar is not just a software engineer and tech lead; he's also a passionate coffee lover with over a decade of experience in the industry. Specializing in front-end and near-frontend technologies, Ildar's expertise spans micro-frontend and micro-service architectures, serverless computing, clean code, and reactive programming.

🎤 Talk: "Domain-Driven Design in Micro Frontend: Hexagon World"

Workshops

We'll have two workshops that you can enter after the conference. These workshops are not paid, but actually quite fairly priced.

Tooling Independent Micro Frontends with Module Federation

In this interactive workshop, you learn to build Micro Frontends using Module Federation without being restricted to the tooling. We start by looking at Module Federation v1 using Webpack - just to progress into Module Federation v2 and its changes. We then show how Module Federation can be used in rspack and Webpack before we look into esbuild and Vite. With each tooling we'll see how the reliance on Module Federation gets more and more decoupled from the tooling, allowing us to make choices on our own.

Trainer: Florian Rappl

🌎 More infos

Micro Frontends with Angular, Federation, and Web Components

In this interactive workshop, you learn to build Micro Frontends with Angular. We discuss integrating Micro Frontends with Module Federation and Native Federation and how to share libraries and data at runtime. We discuss strategies for preventing version conflicts and using web components to implement multi-version and multi-framework scenarios.

Trainer: Manfred Steyer

🌎 More infos

Stay Tuned!

So, mark your calendars for June 17th, 2024, and be sure to register for this exciting event (it's free). Don't miss out on the chance to hear from some of the most prominent figures in the Micro Frontends community and gain invaluable insights into this rapidly evolving field. We look forward to seeing you there!

👉 conference.microfrontends.cloud

(Just remember that you need to confirm your registration. If you did not receive an email with the confirmation check your SPAM folder or get in touch with us, e.g., by commenting below.)

Piral Feed Service 1.13

Florian Rappl — Wed, 28 Feb 2024 07:30:31 +0000

Photo by Clint Patterson on Unsplash

The Piral Feed Service is a commercially available micro frontend discovery service with a free tier that works for many solutions such as Webpack Module Federation, single-spa, Native Federation, OpenComponents, dynamic .NET / NuGet packages, or Piral.

With the release 1.13 the Piral Feed Service adds some new powerful features that make it even more attractive for new teams - giving them some interesting capabilities such as improved support for static websites or instand notifications.

In this post we'll walk over some of the highlights of this release and how these features can impact your work.

Module and Native Federation Enhancements

While the Piral Feed Service had support for (Webpack) Module Federation beforehand, it required the use of the dashboard plugin for Module Federation. Well, no more. Now, the Piral Feed Service is able to detect and use the uploaded micro frontend's correctly as mf, Module Federation.

As for Native Federation there are also a couple of enhancements under the hood. Most importantly, Native Federation just plays nicely with the rest of the functionalities, incl. feature flags, rollbacks, or configurations.

If you are interested in a more specific example check out this repository.

Overall, the view on a feed that only contains micro frontends using Native Federation could look like this:

As mentioned this works nicely with other features - such as all the analysis tools that come with the Piral Feed Service. One of these is the dependency graph:

But the support for other technologies and micro frontend systems does not stop there. With this release there is new kind of feed (and possibility to publish micro frontends) included: NuGet.

NuGet Feed

The NuGet feed is a special representation for .NET-based micro frontends. This plays very well with Piral.Blazor.Server or any other .NET approach that resolves the dependencies of the micro frontends dynamically via the NuGet package manager.

Here is how it can look - it even plays well with some of the analysis.

Accessing the NuGet representation of a feed uses a special link:

https://<feed-service-host>/api/v1/nuget/<feed-name>/index.json

For example:

https://tractor-sample.my.dev.piral.cloud/api/v1/nuget/tractor-sample/index.json

The response to calling this URL is not very interesting - at least for us. However, NuGet is capable of using the information for retrieval of all relevant package information.

There are a few more things in this area - the new release also supports the X-Microfrontend-Type header when publishing. This directly allows supporting other formats than the previously default tgz files. Theoretically, this header allows uploading anything as a micro frontend through one and the same endpoint. In practice we'll see what makes sense to support here.

We also have improvements on the UI for the 1.13.

UI Enhancements

One important element for the 1.13 version was the release of the 1.0.0 of the underlying administration portal. The administration portal is both - super important and super unimportant for the Piral Feed Service.

The importance of the portal is stressed by the fact that most users will actually prefer a graphical UI over plain API calls. Nevertheless, the service is still developed API-first and everything has to be scriptable / doable via the API.

Let's have a look how the UI looks with this update.

Almost every search element is now a backend search using a fuzzy search algorithm. This way some easy searches might take slightly longer than beforehand, but complicated searches don't require a lot of unnecessary data to bloat the frontend. All in all it feels much better.

The more complicated forms, e.g., creation of a new feed, creating an API key, or uploading a new static page is now done with a consistent step-dialog.

The audits (if activated) are now much cleaner and can be investigated with some advanced search options, incl. time-constraints.

Notifications

Starting with 1.13 the Piral Feed Service also includes notification providers. The default notification provider is literally none, i.e., the previous behavior. Right now two other providers exist: One for SendGrid and one for "plain" SMTP. In any case, those two send the notification rather generically in form of an email.

In the configurator you'll now see the notifications section with all available options, as shown below.

Right now notifications are only used on a couple of occasions, e.g., when an API key is about to expire. In the future there will be more notifications with some options to enable or disable them.

There are even more changes, but then again you can just look at the CHANGELOG to see for yourself.

Conclusion

The Piral Feed Service is the most powerful micro frontend discovery service. The free community edition is great to get started. To try the service in your environment you can either go the Azure Marketplace to obtain Azure Container Registry access or contact us to start a free trial of the full service.

AMA - Manfred Steyer on Import Maps for Micro Frontends

Florian Rappl — Fri, 23 Jun 2023 07:52:26 +0000

Some time ago we organized the first "Micro Frontends Conference" - a free fully remote event for the micro frontends community. Pretty much all speakers could make it live to the event, which had a lot of questions asked via YouTube or the Discord community chat. However, one of the speakers was traveling on that day and fortunately decided to still participate by providing a pre-recording of his talk.

Being the great speaker and community member that he is, Manfred Steyer offered to answer the questions for his talk later on. In this article we want to share the answers to the questions asked during his talk.

Questions

So this sounds like another way of doing service discovery, right?

Manfred: Well, if the manifest.json is not just a static json but the result of an “REST” API then it can be used as a kind of service discovery. However, someone needs to implement the management part on the server side.

How would fallback-alternatives be defined for runtime module imports, say using a code split from source if the remote module hosting server is unresposive?

Manfred: You can just use a catch clause when lazy loading the Micro Frontend.

How would this work with React?

Manfred: It works the same way. You find some examples on the npm page. The current challenge with React is that it does not ship ESM bundles. Converting from CommonJS is possible, but there is not the one and only way that works all the time for this. This can be a bit challenging.

The current implementation was tested with React and we even included some solutions for converting to ESM. If you run into troubles, e.g. with some 3rd-party-vendor libs, please let me know.

What was the biggest challenge of building "native-federation"?

Manfred: Honestly, it was straight forward. I had a working POC in some hours, however, making it look like Module Federation took 2-3 additional weeks.

Apart from bundle size - any other reasons to share dependencies?

Manfred: You can also use shared libs to shared data. In this case, the lib acts as a mediator or a mini-service-bus.

Why are we making MFE's so complex, can we not have a standard/specification way of working by hiding all the Impl details and Frameworks/vendor agnostic?

Manfred: That would be great. Currently, nothing is in sight, unfortunately.

In your opinion is better to go lib agnostic or keep with the most supported tooling such as Piral or MFE?

Manfred: Piral works on a higher abstraction level. It’s a framework orchestrating SPAs. The Module Federation approach is more low-level, but it allows you to use your leading framework at the orchestration level. Both approaches have advantages and disadvantages.

I remember your previous talk (JS Kongress) which sponsored the micro frontends with the use of web components. Is the approach you propose today better than the previous one?

Manfred: Using Web Components allows you to abstract differences between frameworks and framework versions. Hence, you can mix and match multiple of them. However, they come with two drawbacks: a) you need some custom infrastructure code for loading them b) by default, each separately compiled web component bundle has all its dependencies.

Hence, if you have 5 bundles, you might get your framework 5 times. Native Federation/ Module Federation compensates for this. For a multi framework/ multi version scenario, you could use Web Components together with Module Federation/ Native Federation. In this case, the dependency is shared when its compatible; otherwise another version is loaded.

Do you see any challenges with native-federation in hybrid apps or webview?

Manfred: Hybrid Apps are not my focus but I have some customers who use module federation with hybrid apps and they told me it works well.

In order to import for future modules and implement an effective cache strategy, we can consider using either versioning /semantic or hashing?

Manfred: For caching yes. For the meta data used by Module Federation/ Native Federation we should go with semver.

Can the modules define "peer dependencies" for the host?

Manfred: Well, at runtime there is no difference between different kinds of dependencies. It’s just a ESM-based bundle loaded on demand.

How does the templates for loading different app fragments look like?

Manfred: Normally, the templates are compiled to EcmaScript. At least, this is the case with all current SPA frameworks. Hence, there is no need to share such templates separately.

Are templates controllable on a per-request basis? - when working on the shell -- how do we get IDE autocomplete for things that remotes expose?

Manfred: You could share an interface. But normally, the contract between different Micro Frontends should be really small.

In the best case, you integrate via the router so that you only need to activate the loaded component without assuming any properties or events. This works well, if you manage to split your application into decoupled vertical parts according to DDD/ Strategic Design.

Are declarations parsed at bundle time?

Manfred: At bundle time Native Federation creates an bundle per shared lib and exposed module found in the federation config.

So, goodbye iframes?

Manfred: Well, iframes still have their use cases. If you need a very good isolation or if you need to integrate traditional web apps (JSP, JSF, ASP.NET, PHP, …) they can be used. Even SAP uses iframes within their Luigi Framework.

Does native-federation want to replace module federation?

Manfred: For me it’s an insurance that the mental model of module federation will live on even if we move away from webpack. Angular, for instance, is slowly moving over to esbuild.

Why not make module federation embrace import maps instead of implementing another standard/lib?

Manfred: To make the mental model of Module Federation tooling agnostic, my take was to implement it mostly outside of the bundler. As a result, you can use with together with other bundlers like esbuild.

single-spa is heavily dependent on import maps. Have you ever compared pros. and cons. comparing their implementation with native-federation?

Manfred: Yes, they use them, and the most common approach to using import maps there is SystemJS. While Single-SPA is a meta-framework, using module federation/ native federation allows you to use your leading framework for orchestrating different micro frontends. No additional framework is needed.

Also, by providing an abstraction, you don’t need to deal with Import Maps by hand. Like Module Federation, Native Federation uses your config and takes care of everything else (putting shared libs in separate bundles, applying strategies for bypassing version conflicts).

How to handle shared dependencies across federated modules? for large projects

Manfred: If you have a monorepo, you can ensure that at a given time, just one version is in place.

If you have several repos, it’s about governance. However, here, you could always get different versions hence abstracting your Micro Frontends with Web Components could be a good idea here.

When does it make sense to use microfrontends?

Manfred: In general, if you have several teams that cannot work together in one monorepo. For me, this is the main reason. On a technical level, Micro Frontends also help with migrating from one tech stack to another one little by little.

Conclusion

Thanks to @manfredsteyer for his participation in this great event and also for answering the questions so swiftly. Much appreciated!

You can follow Manfred on Twitter or get in touch regarding Angular Workshops.

Announcing the Micro Frontends Conference

Florian Rappl — Tue, 09 May 2023 07:31:25 +0000

We are thrilled to announce our upcoming conference for the Micro Frontends community, taking place on June 12th, 2023. This free event is open to anyone interested in the latest developments in this exciting field.

👉 https://conference.microfrontends.cloud/

Audience

This year's conference will be entirely virtual, providing attendees with the flexibility and convenience to participate from anywhere in the world. With no registration fee, the event is accessible to everyone who is interested, making it an excellent opportunity to connect with like-minded individuals from around the globe.

The conference will cover a range of topics, including best practices for implementing Micro Frontends, the latest trends and technologies in the field, and the challenges faced by professionals working in this area. Attendees can expect to learn about everything from component composition and modularization to user interface design and performance optimization.

👉 https://conference.microfrontends.cloud/

Speakers

Michael Geers

Michael is a well-known expert in the field of micro frontends, having written the first wholesome book on the topic, "Micro Frontends in Action." He also initiated the web site micro-frontends.org, which has become a go-to resource for developers and organizations looking to learn more about micro frontends.

Michael's talk, "How Deep Is Your Micro Frontend," will delve into the crucial organizational aspects of implementing micro frontends in your organization. He will share insights and best practices from his extensive experience working with companies of all sizes and industries. Whether you are just starting with micro frontends or looking to optimize your existing architecture, Michael's talk is not to be missed.

Cory Gideon

As a consultant at Sogeti Capgemini, Cory is a well-known expert in system architecture and design for maintainability and scalability.

His talk, "Micro Frontends - Not the Silver Bullet," will focus on different patterns, frameworks, benefits, and pitfalls of implementing Micro Frontends. Attendees can expect to gain valuable insights on how to make the right decision when considering which framework and tool to use for their project. Don't miss out on this incredible opportunity to get some inspirations from one of the best in the industry.

Manfred Steyer

Manfred is a well-known figure in the Angular community and has been instrumental in bringing micro frontends to the forefront of the discussion. He has authored several crucial plugins and even written a book about Angular and micro frontends, which is available for free.

In addition to his work as an author and developer, Manfred is also a highly sought-after speaker and trainer for Angular. He has led numerous workshops and has helped countless developers gain a better understanding of Angular and micro frontends.

At the conference, Manfred will be giving a talk entitled "Import Maps - The Next Evolution Step for Micro Frontends?" In this talk, he will discuss the next step for micro frontends - becoming truly native citizens of the web without the need for frameworks or special tooling. With his extensive knowledge and experience in the field, Manfred is sure to provide valuable insights and thought-provoking ideas that will help shape the future of micro frontends.

Stefan Bley

Stefan is a software architect at ZEISS Digital Innovation, where he leads a team that is pioneering the use of micro frontend architecture in healthcare digitization.

Stefan is passionate about experimenting with new technologies and ways of working, and he brings that enthusiasm to his talk "Healthcare Goes Micro: A Case Study in Frontend Modularity." In his presentation, he will dive into the challenges that come with building a large-scale healthcare platform using micro frontends. This is a particularly intriguing topic because healthcare is a highly regulated industry, and the concepts and ideas of teams have traditionally been geared towards monolithic solutions.

During his talk, Stefan will share his experience in crafting and implementing a modular, performant frontend architecture for ZEISS's healthcare platform. His talk is a must-attend for anyone interested in micro frontends, healthcare digitization, or software architecture in general.

Giorgio Boa

Giorgio is a talented full-stack developer at Claranet, who has a passion for frontend development and improving the frontend ecosystem. With his extensive knowledge of modern JavaScript capabilities, Giorgio is always looking for ways to enhance the developer experience.

In his talk, "Micro Frontends with Qwik," Giorgio will dive into the concept of micro frontends with #Qwik. As we all know, micro frontends are a popular approach for building scalable, flexible web applications. With the help of Qwik, a lightweight web framework for building web applications, developers can quickly and easily create micro frontends. Giorgio will show how Qwik can improve the developer experience and make building micro frontends faster and more efficient.

Attendees can expect to learn about the benefits of using Qwik for micro frontend development, how it can simplify the process, and how to use it effectively. Giorgio will also share some of his insights and experiences in working with Qwik and modern JavaScript capabilities such as importmaps.

Ruben Casas

Ruben is a staff engineer at Postman and is well-known in the industry for his expertise in micro-frontends and large-scale frontend applications.

In his talk "The Evolution of Micro Frontends", Ruben will guide attendees through the various stages that frontend applications go through in their mission to scale. He will discuss the transformation from a monolith to a modulith and ultimately to a micro frontends solution. In less than an hour, attendees will witness a decade of scaling experiences and learn about the practical and innovative solutions Ruben has implemented along the way.

Ruben's experience in designing and implementing solutions for large-scale frontend applications makes him an invaluable addition to our conference. Attendees can expect to gain invaluable insights and practical tips to help them tackle the challenges of scaling frontend applications.

Daniel Ostrovsky

Daniel is a Senior Principal Engineer at Dell. He is well known for his enthusiasm and guiding expertise within the Angular community.

With many years of experience, Daniel's talk "Micro Frontend Architecture and Module Federation: Making the Right Choices for Your Project" will address important questions like when to use micro frontends and if module federation is the right choice for your project at all. Don't miss this opportunity to learn from a seasoned expert to refine your projects.

https://github.com/danduh

Luca Mezzalira

Luca has made a significant contribution to the micro frontends community with his insightful talks, blog posts, and his book "Building Micro Frontends".

Luca's talk, "Micro Frontends Discovery," is a must-see for anyone working with micro frontends. One of the most significant challenges of micro frontends is how to develop and maintain them independently without changes to the exposed web application. Luca will address this challenge by introducing the concept of discoverability, which enables the dynamic retrieval of micro frontends. By attending this talk, you'll learn how to make your micro frontends more manageable and flexible than ever before.

Zackary Jackson

Zackary is a Principal Engineer at lululemon. He is a renowned expert in distributed software self-formation and orchestration at runtime, and his work on Webpack Module Federation has made him a household name in the micro frontends community.

His talk "Module Federation & SSR" will focus on using Module Federation with use-case in server-side rendering. He'll dive into the details of setting up and configuring Module Federation and explore use cases such as lazy loading and runtime sharing. This is a can't-miss opportunity for anyone interested in learning more about micro frontends and their application in server-side rendering.

Florian Rappl

Florian is a Solution Architect at smapiot and co-organizer of the conference. He is well known in the micro frontends community by his articles, his book ("The Art of Micro Frontends"), and as the core maintainer of the popular Piral framework for micro frontends.

His talk discusses Florian's journey in the micro frontends space covering the last 7 years and looking into the next three as much as possible. He will also show a new way how to do micro frontends combining several cutting edge techniques - coming up with a serverless progressive edge-rendering sea of islands developed independently in different micro frontends.

Merchandise

We also are happy to announce that we have some T-shirts and other cloths for purchase in our webshop. If you want to support the conference or show your passion for scalable frontend development then this is for you.

https://www.seedshirt.de/shop/micro-frontends-conference

If you're attending the conference and want to show your support for this free community event, consider purchasing a piece of merchandise from the webshop. Not only will you be able to represent the conference with pride, but your purchase will help support the organizers in continuing to provide high-quality content for the micro frontends community.

Head over to the webshop now and check out the selection. Don't forget to share your swag on social media and tag us!

Stay Tuned!

So, mark your calendars for June 12th, 2023, and be sure to register for this exciting event. Don't miss out on the chance to hear from some of the most prominent figures in the Micro Frontends community and gain invaluable insights into this rapidly evolving field. We look forward to seeing you there!

👉 https://conference.microfrontends.cloud/

(Just remember that you need to confirm your registration. If you did not receive an email with the confirmation check your SPAM folder or get in touch with us, e.g., by commenting below.)

Piral Feed Service 1.10

Florian Rappl — Mon, 03 Apr 2023 09:21:47 +0000

With the release 1.10 the Piral Feed Service adds some new powerful features that make it even more attractive for new teams - giving them some interesting capabilities such as standalone feature flags out of the box.

In this post we'll walk over some of the highlights of this release and how these features can impact your work.

Micro Frontend Infos

Previously, the Piral Feed Service only showed some information of a micro frontend such as the used version or the name of the micro frontend.

With the arrow icon on the right hand side you can now show additional information.

This is great to see what's the size of the micro frontend, how it's structured and what dependencies are there (and if they are shared).

In case of an uploaded README.md file you even get to see some documentation of the micro frontend:

This aligns quite well with previously available views such as the dependency view, which is available since quite a while:

All in all, it is now possible to inspect the published micro frontends even better - yielding all kinds of useful information.

Feature Flags

Many of our customers told us that the included feature flag / rule evaluation from the Piral Feed Service is more powerful and works even better than dedicated feature flag services such as LaunchDarkly, Split, or Azure Configuration. What was missing is a way to have dedicated or standalone feature flags, which are independent of micro frontends and could be used within micro frontends, or some other application.

This is now possible. Every feed has a new action item called "Manage Feature Flags".

Following this action you can create new feature flags using an identifier and description.

Once created the feature flags are available - and can also be fully toggled:

There is a dedicated URL to retrieve the available feature flags. Following the /api/v1/feature/{feed} URL you'd get a response that includes the flags property:

{
  "feed": "example",
  "flags": ["feature1", "feature2"]
}

Only the enabled features for the given request are listed.

For instance, if you have a rule for a feature "my-feature" like the following:

{
  "type": "query",
  "name": "access",
  "compare": {
    "type": "eq",
    "value": "456"
  }
}

then the flag would show only if /api/v1/feature/example?access=456 is requested:

{
  "feed": "example",
  "flags": ["my-feature"]
}

But not otherwise (e.g., /api/v1/feature/example?access=123):

{
  "feed": "example",
  "flags": []
}

The best thing about feature flags is that they are also a way to re-use rules across multiple micro frontends. Let's say you want to re-use the rules for my-feature above in two micro frontends, you can just create a single rule for each micro frontend:

{
  "type": "feature",
  "name": "my-feature"
}

This way, you can easily make feature flags your primary mechanism for toggling micro frontends, without having to duplicate their rules.

Publish Overrides

One thing that the Piral Feed Service implemented from the beginning is protection against version conflicts. As such it prevented publishing one micro frontend again using the same version.

While this is great and enables a lot of optimizations (e.g., micro frontends are ensured to be immutable and therefore can be cached indefinitely) it also comes with convenience drawbacks. To mitigate this a special "preview" property has been added to the package.json. If a micro frontend has

{
  "name": "my-mf",
  "version": "1.0.0",
  "preview": true
}

then the Piral Feed Service would always append a special preview suffix (e.g., making the version 1.0.0-pre.1234). The downside of this approach was that the property is part of the package.json and therefore not something that is easily enforceable, e.g., just for a certain branch or publish action.

Now, the Piral Feed Service supports various overrides such as version or preview:

# change the version to be a preview
npx publish-microfrontend --url ... --interactive --fields.preview on

# change the version to be 1.2.3
npx publish-microfrontend --url ... --interactive --fields.version 1.2.3

While the first call overrides the preview flag of the package.json (i.e., it does no longer require that or changes its value if that property exists), the second changes the provided version. Both overrides also work together.

Additional Rules

As mentioned, the rule engine provided by the Piral Feed Service is definitely a powerful one - and features many possibilities that make dynamic rule evaluation and feature management convenient and flexible.

One thing that was wished here was time-based evaluation. While this could be introduced via custom rules, we thought that this is a great generic addition that should not be missed here.

There are three new rule types here (not_before, not_after, and cronjob). The first two are also available in a new wizard:

If you follow the wizard you'll get the option to define a time window using a not before / not after date. The times are always given in UTC.

Using this you can easily either make your micro frontends expire (e.g., for a given deal you want to show some preview here, but once the deal is off the table you want to also hide the content of the micro frontend) or just go online at a certain point in time (your big rollout is on Monday 6am, but no developer will be available - just make sure to have everyone publish their micro frontend beforehand and set the rule to make the micro frontend available at Monday 6am).

In contrast, using cronjob is for re-occurring rules, i.e., when your micro frontend should only available on Sundays or during office hours.

For instance, the following rule will activate a micro frontend at 9am UTC for 3 hours every day:

{
  "type": "cronjob",
  "duration": 180,
  "hour": 9,
  "minute": 0
}

If the duration is skipped then it will match the whole day after the time is met.

Conclusion

Docker Content Trust on ACR with Azure Pipelines

Florian Rappl — Tue, 02 Aug 2022 21:56:22 +0000

Photo by krakenimages on Unsplash

Docker Content Trust (DCT) is a mechanism to improve the security of Docker images. Since we are working together with large enterprises and governments we are slowly but surely pushed into a direction to implement every possible mechanism to strengthen security for the Piral Feed Service.

Our whole infrastructure - from code repositories to build processes to actual runtime environment - is in Azure. For us this has some benefits. Luckily, one benefit is that enabling DCT on Docker images published to the Azure Container Registry (ACR) is quite easy. Another benefit is that these images can be published rather easily. Unfortunately, I did not find very good sources for this - so I decided to write up the steps that worked for me.

The ultimate goal of these steps is to change an existing Azure Pipeline for building and publishing a Docker image from not using DCT to using it, i.e., publishing signed images.

Useful References

The resources that I found useful up to some degree are:

Preparation

Without further ado let's start by breaking down the process.

(Azure) enable DCT on the target ACR
(Azure) assign the necessary roles to the user account and service principal
(Local) create private and public delegation keys
(Local) initialize the (ACR) repository with the private key
(Azure) add the private key to the pipeline secrets
(CI/CD) change the Azure Pipeline to use DCT when publishing

Steps 1-5 are all preparation steps. The real work is done in step 6.

Enable DCT on ACR

The first - and presumably most simple - step is to enable Docker Content Trust in the ACR blade of the Azure Portal. Select your ACR and set the "Content Trust" to "Enabled".

Note that this option is only applicable for premium registries. If you have a basic SKU then you'll not see this option.

Besides turning on the DCT you'll also need to assign a certain role to service principals and users that should be able to use this feature.

Assign Roles

A key point in this section is to identify which service principal(s) you need to give the special role to allow signing images. Here, you need to find out what service principal(s) have been created when you established the service connection to the ACR in your Azure Pipelines project.

Each created service principal consists of multiple IDs. The ones that are shown directly in the Azure Portal are:

the client (or application) ID
the object ID

The latter is what we need to identify. The connection to Azure Pipelines is usually visible via the name. It should contain the Azure DevOps organization and project name. In addition, it will usually end with a GUID representing the chosen Azure subscription.

The service principals created by Azure Pipelines for new service connections to an ACR all have the push role assignment (AcrPush). If we identify those, we can just use them to give them the AcrImageSigner role.

First, let's click on the accounts in the role assignments overview tab. The information should look a bit like that:

Now, let's add new roles by clicking on "Add". Select "Add Role Assignment".

Finally, we can assign new roles. Make sure to pick the AcrImageSigner role. Then add new members, picking the previously selected service principal(s).

When everything is done you should see a role assignment overview similar to the one shown below. Important part is that the service principal(s) in question have both, the AcrPush and AcrImageSigner roles.

Also make sure to give your own account the AcrImageSigner role. This will be important to actually initialize the ACR repository later on.

Create Delegation Keys

Now it's time to actually create the keys. For this, you should have a nix environment (MacOS, Linux, WSL) and the OpenSSL toolchain installed.

First, let's generate a new key:



openssl genrsa -out delegation.key 2048

Now we can actually pair the private key with a public one - ready for a signing request.



openssl req -new -sha256 -key delegation.key -out delegation.csr

It is sufficient to self-sign the key. Let's do that - keeping the public key active for a year.



openssl x509 -req -sha256 -days 365 -in delegation.csr -signkey delegation.key -out delegation.crt

Now we set the access rights such that no one else can read or write the private key. If we don't do that the Docker tooling will refuse to work with the key.



chmod 600 delegation.key

Once done we can tell Docker to use the key as signing source. We can give it a name to identify it (locally) again. I've chosen to just give it the company's name.



docker trust key load delegation.key --name smapiot

This is great - the key is now ready and we can initialize the repository.

Initialize ACR Repository

Now that we set up everything we can "initialize" the repository. This is the step to actually teach the ACR about our generated key. For security reasons this step is quite important.

After all, up to this point anyone could come, somewhat sign an image and say "hey it's signed - so it's fine". No, it's not. It should be a specific signature. And by initializing the repository we make sure to pin the repository to a specific signature.

We start by logging into Docker using the Azure CLI. This way, we will actually use Docker with a 3 hour valid access token pinned to our account. Since we gave our account the AcrImageSigner role we can use it to initialize the repository.



az acr login --name piral.azurecr.io

The actual step is to add the signer using the public certificate and the key using the docker CLI:



docker trust signer add --key delegation.crt smapiot piral.azurecr.io/piral-feed-service

Now, we can actually inspect the delegation key for the given repository.



docker trust inspect --pretty piral.azurecr.io/piral-feed-service

Which should give something similar to the following output:



No signatures for piral.azurecr.io/piral-feed-service


List of signers and their keys for piral.azurecr.io/piral-feed-service

SIGNER    KEYS
smapiot   123...

Administrative keys for piral.azurecr.io/piral-feed-service

  Repository Key:       987...
  Root Key:     abc...

The important part is to note down the repository key. We will need this for the pipeline.

Add Private Key to Pipeline Secrets

We need to store / use three values within our pipeline:

The private key file. This should be uploaded / stored as a pipeline secret, e.g., in a library via the secure files feature.
The used passphrase for the key. When we added the signer earlier one we had to set up a passphrase. Now, we need to provide this passphrase.
The repository key of the used key. We could also just rename the file uploaded in (1) to the used key.

Pipeline Adjustments

Now to the grand finale... In the azure-pipelines.yml we'll need to go from something like a buildAndPush command to a more explicit (and lengthy) variant.

Let's say we started with something like the following:



- task: Docker@2
  inputs:
    command: buildAndPush
    dockerfile: ./Dockerfile
    repository: $(dockerImageName)
    containerRegistry: $(dockerRegistryConnection)
    tags: |
      latest

We now need to decompose this into the different parts (login, build and push) and enhance it with the DCT settings.

Importantly, we need to import the file we placed in the secure files library. This file should be renamed to the ID we've found out previously. It should also be configured correctly; such that no one else could read it.

Let's see the code quickly:



- task: Docker@2
  inputs:
    command: login
    containerRegistry: $(dockerRegistryConnection)

- task: DownloadSecureFile@1
  name: contentTrust
  inputs:
    secureFile: 'docker-content-trust.key'

- script: |
    mkdir -p $(DOCKER_CONFIG)/trust/private
    cp $(contentTrust.secureFilePath) $(DOCKER_CONFIG)/trust/private
    echo "Copied $(contentTrust.secureFilePath) to $(DOCKER_CONFIG)/trust/private"
    mv $(DOCKER_CONFIG)/trust/private/docker-content-trust.key $(DOCKER_CONFIG)/trust/private/$KEY_ID.key
    chmod 600 $(DOCKER_CONFIG)/trust/private/$KEY_ID.key
    docker trust key load $(DOCKER_CONFIG)/trust/private/$KEY_ID.key
  env:
    DOCKER_CONTENT_TRUST_REPOSITORY_PASSPHRASE: $(dockerContentTrustPassphrase)
    KEY_ID: 987...

- task: Docker@2
  inputs:
    command: build
    dockerfile: ./Dockerfile
    containerRegistry: $(dockerRegistryConnection)
    repository: $(dockerImageName)
    tags: |
      latest
    arguments: '--disable-content-trust=false'

- task: Docker@2
  inputs:
    command: push
    containerRegistry: $(dockerRegistryConnection)
    repository: $(dockerImageName)
    tags: |
      latest
    arguments: '--disable-content-trust=false'
  env:
    DOCKER_CONTENT_TRUST_REPOSITORY_PASSPHRASE: $(dockerContentTrustPassphrase)

In there we are also using the previously set dockerContentTrustPassphrase. This is required at all position where either we just consume DCT signed images or where we want to consume such images.

Conclusion

Setting up DCT with the ACR is not difficult, but requires quite some steps. Together with some - not very well documented - behavior (e.g., name of the file, file access rights, ...) the whole process can be more tedious than it actually needs to be.

The gained security is definitely worth the effort. Now, images have an additional layer of trust that is easily verifiable by consumers - much to the liking of large enterprises and governments.

Getting Started with Micro Frontends

Florian Rappl — Mon, 18 Jul 2022 07:54:45 +0000

Photo by Mourizal Zativa on Unsplash

What are Micro Frontends?

With most of the current state of development of a web application, we generally see that it's a feature-rich and powerful application, and it's called a Single Page App or SPA. These types of applications are made using a single frontend framework or library like Angular, React, etc.

But over time, as we see all around, the application in itself grows more in many features and complexity and, in turn, can be challenging to maintain, especially when a separate team develops it. This is what we call a monolith approach.

On the other hand, we have the approach to using Micro Frontend architectures. Simply put,

Micro Frontends are a pattern where web applications User Interfaces (UIs) or a frontend are composed of independent or semi-independent fragments that can be built by different teams using different technologies or tech stacks.

With a micro frontend, you can have a modularized structure of a microservice backend. Thus, micro frontends resemble backend architectures where each backend is composed of semi-independent/independent microservices.

It's an architectural style of building more robust web apps where independently deliverable frontends are composed into a more significant whole unit. These micro frontends extend the ability to make web applications as separate parts of a whole, right from the database all the way up to the raw HTML.

Benefits and Challenges to Micro Frontends

Recently, "micro frontends" has become a buzzword in tech, and for the right reasons, it changes the way developers think about web application development architectures.

In this section, we will deal with what benefits you get by using micro frontends and what are some of the disadvantages or challenges that it faces today in real-world apps.

Benefits of Micro Frontends

Some of the top benefits on why you should choose them are:

Iterative approach to app updates: micro frontends aim at decreasing the size and prominence of the traditional monolith architecture for greater update flexibility. These micro frontends can maintain backend functionalities without much friction, and it doesn't affect the other parts of the code.

With this, organizations can move quickly and effectively in their app update cycles without external side effects. The User Experience (UX) is also improved as micro frontends can break large-scale workflow systems into smaller components. From there, creating, scaling, and updating any business logic becomes easier for an improved end consumer experience.

Hence, they prove to be incredibly useful with more iterative updates, which in turn decreases the cost and complexity of the whole process.
Independent deployment and testing: when you work with a micro frontend, they are independent; this means that deployment and other changes will affect only that specific microservice used in that change. It doesn't cause any change to the whole app.

By this, the development and testing teams can focus only on monitoring one aspect of the whole app while avoiding the need for the entire project to be tested or monitored at the same time.
Helps to develop different views of your processes relevant to each person’s role: using micro frontends, you can quickly create different views for each person's unique role in a process-driven application.

Traditionally, when you build SPAs, you create one app for each user role. But a micro frontend architecture enables you to make changes quickly for any number of different roles. Also, it becomes easier to update these elements as your app responds to the user's needs and business logic.
Makes your web application more maintainable: if you're a seasoned developer using the monolith approach, you would know that testing and maintaining large applications is really hard, challenging, and take a lot of time.

But as we know micro frontend approach is like divide and conquer; by choosing this architecture for your next web application, you can easily make your business requirements easier to test and maintain.

By having smaller chunks of application, it's much more affordable to understand the flow of what's happening, making them more reliable and easy to maintain by teams.
Allows you to democratize user experience: like microservices democratized backend development workflow, micro frontends allow to enable this service-oriented culture to extend to all parts of the development lifecycle.

It allows both the frontend and the backend teams to iterate independently at their own pace rather than being held up by organizational barriers. This decreases the bottlenecks in favor of better communication between developers allowing cross-functional teams to work autonomously.

Challenges of Micro Frontends

These are the five challenges to keep in mind:

Complexity: with too many components to break down in an application, developers may overpopulate their project as time goes in building the app. This causes multiple testing to be done and issues to occur while deploying across several teams.

Without detailed planning of what type of components to employ and how many of them, the process can become complex if not handled well. All of this costs more time on management and resources.
Workflows crossing boundaries: it can be very challenging to both create and maintain workflows shared between micro frontends and the shell.

Different teams can update each application and, therefore, can be released and changed independently. But suppose in your web app, rather than using the built-in navigation utilities, you build your custom navigation system that adds to the complexity. For this, you must pass the app state across separate applications and check who is responsible for saving the complete app state.

If you make a change to one of your frontends, you will need to test that all of the connected multi-workflows are still intact and working as expected. You end up having test version checks all over the place.
Payload: the issue of payload comes into the picture once we get to see that if a micro frontend requires a specific program/library to be installed client side in order to function, then the client also needs to download its corresponding copy as a payload while accessing the application.

This problem worsens when each component must ensure multiple payloads are downloaded for proper browser support. Anytime extra data demand is a disadvantage as the user may not return back to using your app, having poor performance.
Reducing discoverability leads to duplicate implementations: with the approach of splitting an application, the ability to discover existing code may go down. Next, you need to search deep in your project's codebase for what pieces of code are to be reused.

While working with teams, refactoring becomes an issue as you don't want to be responsible for refactoring a code of an unfamiliar project to get access to a shared component.

All this leads to duplicate implementations across separate frontends. And as you may know, having duplicate components means higher costs over time. Future changes will now require more significant changes in diverse places of your app, and ultimately this leads to a buggy application.
Environment differences: we would usually strive to develop a single micro frontend without thinking about all of the other ones being developed by other teams. This might make development more straightforward, but there are certain risks associated while growing in an environment that is starkly different from the production one.

If our development container behaves differently than the production one, we may find that our micro frontend is either broken or doesn’t perform as expected. For example, the global styles brought along by the container or other micro frontends might be very different.

Comparing Micro Frontends Solutions

With the rise of micro frontends, we also see that many solutions are coming up to tackle particular challenges, as discussed above.

Some of these solutions give you smart build-time integrations of components, and some provide you with dynamically imported code from another app. In this section, let's take a look at three of the major solutions we currently have for micro frontends:

1) Single SPA: in short Single SPA is:

A JavaScript router for frontend microservices.

It is a framework for bringing together multiple JavaScript micro frontends in a frontend application and is mostly concerned about cross-framework components. This means you use multiple frameworks, like React, Angular, Ember, etc., on the same page without refreshing the page.

It applies a lifecycle to every application. In this, each app responds to URL routing events and must know how to mount/unmount itself from the DOM. Single SPA is best suitable if you want to put together different frontends/frameworks into one DOM to integrate at runtime.

2) Module Federation: this is built on the principle that:

Multiple separate builds should form a single application. These different builds should not have dependencies on each other, so they can be developed and deployed individually.

Generally, Module Federation only takes care of dependency sharing and is heavily tooling dependent. For example, once you're downloading a React component, your app will not import the React code twice once it's loaded, and it will use the source you already downloaded and then only import the component code.

The above two frameworks we saw are strongly coupled, i.e., you cannot disable the micro frontend, and then you also get feature overlap where one micro frontend depends on a specific version of another.

3) Piral: Piral is a framework for next-gen portal applications.

It allows you to quickly build web apps that follow the micro frontends architecture.

Piral takes care of everything you need in order to create distributed web applications with the flexibility and modularized structure of a microservice backend.

It helps you to create a modular frontend application extended at runtimes and comes with decoupled modules called 'pilets.' A pilet can be used to:

Bring the functionality, queries, and mutations for the application.
Include your own assets and dedicated dependencies.
Define where you want to integrate the components.

Piral's application shell is called a Piral instance, which:

Brings the overall design of the application (e.g., header, footer, navigation, etc.)
Includes shared components that can be used by pilets.
Defines how pilets are loaded and where pilets can integrate their components.

Here, Piral differs from the other two in the list as it is loosely coupled and lets you always deploy your micro frontend without depending on another micro frontend. It doesn't matter if it's always there; apps made with Piral always work.

Creating your first application with Piral

Getting started with Piral is actually quite smooth and easy. The documentation page has all the steps. Besides the option of starting with an app shell that holds together all micro frontends we can also directly start with micro frontend development for an existing app shell.

The team behind Piral created some ready-to-use app shells. One of these is the "sample-piral" app shell. Starting development for a micro frontend for this app requires only npm and Node.js. In the command line of a new directory run:



npm init pilet -- --source sample-piral --bundler esbuild --defaults

Remark: In order versions of npm (6) the forwarding dashes (--) can be left out.

Now the pilet should be ready. Let's have a look at the code. The most important file is the src/index.tsx. Here, everything comes together. Let's change the original code from the following:



import * as React from 'react';
import { PiletApi } from 'sample-piral';

export function setup(app: PiletApi) {
  app.showNotification('Hello from Piral!', {
    autoClose: 2000,
  });
  app.registerMenu(() =>
    <a href="https://docs.piral.io" target="_blank">Documentation</a>
  );
  app.registerTile(() => <div>Welcome to Piral!</div>, {
    initialColumns: 2,
    initialRows: 1,
  });
}

to only expose a page that is made visible via a link:



import * as React from 'react';
import { Link } from 'react-router-dom';
import { PiletApi } from 'sample-piral';

const MyPage = React.lazy(() => import('./Page'));

export function setup(app: PiletApi) {
  app.registerMenu(() =>
    <Link to="/my-page">My Page</Link>
  );
  app.registerPage("/my-page", MyPage);
}

In the code we are - besides the setup function itself - not using anything custom. Using Link and React.lazy are familiar to any developer of React. This is the basic philosophy behind Piral. Pilets should just use the concepts of the underlying frameworks. Therefore, no meta router like in single-spa is required. The only new concept is that components now need to be registered where / how they should be used.

The code for the page is in src/Page.tsx. It reads:



import * as React from 'react';
import { PageComponentProps } from 'sample-piral';

const Page: React.FC<PageComponentProps> = ({ piral: app }) => {
  return (
    <>
      <h1>My Page</h1>
      <p>This is some text.</p>
      <app.Extension name="important-info" />
      <p>Some more text.</p>
    </>
  );
};

export default Page;

The page is actually quite simple in its logic. But looking closely you see that we also placed one special element in there. The provided piral prop refers back to the API that allowed us to register pages and more earlier on. Now we can use the same API to create an extension slot.

An extension slot is a construct that is quite similar to what web components can offer. Let's say we have the following HTML code:



<h1>My Page</h1>
<p>This is some text.</p>
<x-important-info></x-important-info>
<p>Some more text.</p>

If some script is loaded that does a call to customElements.define with an element "x-important-info" then something will be shown. Otherwise, the spot may just remain empty.

Unfortunately, web components have quite a few downsides which make them less ideal for such placeholders:

They cannot be undefined, so no way to remove micro frontends cleanly
They cannot be defined multiple times, so no way of multiple micro frontends contributing to a placeholder
They are bound by the HTML model with string-based attributes, which does not work together so nicely with some UI frameworks such as React

Nevertheless, to actually illustrate what an extension slot is web components provide a useful model.

Let's start the micro frontend by running



npm start

which will - under the hood - run pilet debug. The browser will show a page like this:

For testing purposes we can also fill the placeholder spot. To do that we can actually register an extension ourselves in the src/index.tsx. Change it to be:



import * as React from 'react';
import { Link } from 'react-router-dom';
import { PiletApi } from 'sample-piral';

const MyPage = React.lazy(() => import('./Page'));

export function setup(app: PiletApi) {
  app.registerMenu(() =>
    <Link to="/my-page">My Page</Link>
  );
  app.registerPage("/my-page", MyPage);

  if (process.env.NODE_ENV === 'development') {
    app.registerExtension('important-info', () => (
        <p>
            <strong>WARNING</strong> Test extension
        </p>
    ));
  }
}

The browser should update automatically. The page now looks like this:

Great! So how do you bring such a micro frontend online? There are multiple ways, but the most straight forward way may be to use the official Piral Cloud feed service. This service is free for personal development purposes. You can just log in via an existing Microsoft account at https://feed.piral.cloud.

When clicking on "Create Feed" you can enter a new (unique) feed name and some details.

Now click create and finally you are on a page where the current pilets are shown. Right now we have none.

We can now either create an API key and publish the pilet from the command line, or we just upload the pilet via the web interface. Let's automate this right away by clicking on the symbol ("Manage API keys"), then clicking the button "Generate API Key".

Give the key a name, but leave the rest as is. The default scope ("pilets.write") is sufficient. Then click on "generate". Click on the generated key to copy it.

On the command line run from the pilet's directory:



npx pilet publish --fresh --api-key <copied-key> --url <feed-url>

where the copied-key part should be replaced by the key you copied. The feed-url must be replaced with the URL from your feed. In my case the command looked like:



npx pilet publish --fresh --api-key bd3e907b54c1b275cc... --url https://feed.piral.cloud/api/v1/pilet/vk-pilets

The portal should auto update and now list the pilet:

Wonderful - you've just published your first micro frontend. But how can you use it? After all, we don't have any page online. One thing we can do here is to just clone the repository of Piral - where the sample-piral app shell is developed. However, this is rather cumbersome and not great. The other thing is to just scaffold a new app shell and point it to the current feed.

In a new directory run:



npm init piral-instance -- --bundler esbuild --defaults

Once installed open the src/index.tsx in your text editor and change



const feedUrl = 'https://feed.piral.cloud/api/v1/pilet/empty';

to be



const feedUrl = 'https://feed.piral.cloud/api/v1/pilet/vk-pilets';

where the specific URL is the one you used to publish your pilet earlier. Now run npm start on the command line.

Even though the overall design is different we still get an entry in the menu (though looking a bit different, of course). And most importantly we still have the page. With this in mind let's stop the debugging, create and publish a second pilet, and see both coming together.

In a new directory, run again the npm init command for a pilet. Again, we can choose the sample-piral as app shell for trying / debugging the pilet. Change the src/index.tsx to be:



import * as React from 'react';
import { PiletApi } from 'sample-piral';

const MyExtension = React.lazy(() => import('./MyExtension'));

export function setup(app: PiletApi) {
  app.registerExtension("important-info", MyExtension);
}

The file src/MyExtension.tsx looks like this:



import * as React from "react";

function MyExtension() {
  const [count, setCount] = React.useState(0);
  const increment = React.useCallback(() => setCount((count) => count + 1), []);

  return (
    <div>
      <button onClick={increment}>Clicked {count} times</button>
    </div>
  );
}

export default MyExtension;

Just a simple counter - not more. We only use this example to demonstrate how easy it is to bring interactive components from one thing to another. This component is actually lazy loaded in its position. So it will only be made available when some slot would demand it, which is great for performance reasons.

Once published we can go back and look at the aggregation of both micro frontends in the same view:

Even without running our own shell we could debug both together. The piral-cli supports running multiple micro frontends at once. From the first pilet run:



npx pilet debug ../first-pilet ../second-pilet

where you can replace the names of the two folders with the paths you gave your pilets.

Congratulations! You just created two pilets that are capable of running in different app shells and bring features to each other without depending on each other.

Conclusion

In this article guide, we learned all about micro frontends in detail. We started by introducing you to micro frontends, how they differ from traditional SPAs and what problems they solve. Then, we stated a few of its benefits and challenges regarding how good it is with its independent iterative approach and how payloads and environment differences still pose a challenge.

Next, we compared different approaches to micro frontends briefly. We finally saw how to create your first app with Piral using the Piral Feed Service.

DEV Community: smapiot

Hyper-Scale Activated! Ship Your Own FaaS 🤖

Prerequisites

Architecture

Writing the Server

Making the Server Dynamic

Evaluating Modules from URLs

Example Functions

One Module

Two Modules

TypeScript Modules with Dependencies

Deployment

Advanced Dynamics

Conclusion

MDX with Translations 🐠

Website Structure

Integrating MDX

Providing Translations

Conclusion

Faster Pages with React ✨

The Origins

Going into SSG

Modernizing the Stack

Lighthouse Issues

Improvements

Final Touches

Conclusion

Announcing Micro Frontends Conference 2024

Audience

Speakers

Michael Geers

Dmitriy Shekhovtsov

Cathrin Möller

Juan Carlos

Florian Rappl

Mo Javad

Daniel Ostrovsky

Shelly Goldblit

Zackary Jackson

David Serrano

Jennifer Wadella

Stefan Bley

Lucas Braeschke

Luca Mezzalira

Manfred Steyer

Ildar Sharafeev

Sponsors

Workshops

Tooling Independent Micro Frontends with Module Federation

Micro Frontends with Angular, Federation, and Web Components

Stay Tuned!

Piral Feed Service 1.13

Module and Native Federation Enhancements

NuGet Feed

UI Enhancements

Notifications

Conclusion

AMA - Manfred Steyer on Import Maps for Micro Frontends

Questions

Conclusion

Announcing the Micro Frontends Conference

Audience

Speakers

Michael Geers

Cory Gideon

Manfred Steyer

Stefan Bley

Giorgio Boa

Ruben Casas

Daniel Ostrovsky

Luca Mezzalira

Zackary Jackson

Florian Rappl

Sponsors

Merchandise

Stay Tuned!

Piral Feed Service 1.10

Micro Frontend Infos

Feature Flags

Publish Overrides