DEV Community: okmttdhr

What is "Lane" in React?

okmttdhr — Thu, 15 Jul 2021 00:49:54 +0000

A concept called "Lane" is used inside React.

Initial Lanes implementation by acdlite · Pull Request #18796 · facebook/react

React 18 alpha was recently released, and many of the concurrent features are based on the Lane.

Lane is a 32-bit representation of a task at reconcile time, and the actual code for Lane is as follows;

// https://github.com/facebook/react/blob/9212d994ba939f20a04220a61e9776b488381596/packages/react-reconciler/src/ReactFiberLane.new.js
const NoLane: Lane = 0b0000000000000000000000000000000;
const SyncLane: Lane = 0b0000000000000000000000000000001
const TransitionLanes: Lanes = 0b0000000001111111111111111000000;
const IdleLane: Lanes = 0b0100000000000000000000000000000;
const OffscreenLane: Lane = 0b1000000000000000000000000000000;

As you can see, lanes exist for each type of task, with the exception of NoLane (when there is no task), but basically lanes with higher priority are represented by smaller numbers.

By using 32 bits, bitmask can be used to manipulate lanes. For example, if multiple lanes are bitmasked into one lane, there is no need to compare all lanes relative to each other, which simplifies implementation and saves memory.

Let's take a look at the actual function that performs bitmasking.

export function mergeLanes(a: Lanes | Lane, b: Lanes | Lane): Lanes {
  return a | b;
}

This function, as the name suggests, merges lanes and returns them. For example, it can be used as follows.

mergeLanes(
  NoLane /*0b0000000000000000000000000000000*/,
  OffscreenLane /*0b1000000000000000000000000000000*/
)

// => 0b1000000000000000000000000000000

In the above example, a Lane with no tasks (NoLane) is updated to an OffscreenLane. Since Lanes are attached to Fiber, we can update the Lane of the target Fiber as follows.

fiber.lanes = mergeLanes(
  fiber.lanes /* NoLane */, 
  OffscreenLane
)
// => OffscreenLane

Let's take another look at the function isSubsetOfLanes.

export function isSubsetOfLanes(set: Lanes, subset: Lanes) {
  return (set & subset) === subset;
}

This function returns whether or not the result of the AND operation of Lane matches the subset. It is not clear what makes it useful, so I will try to write some more specific patterns.

isSubsetOfLanes(
  NonIdleLanes, /*0b0001111111111111111111111111111*/
  SyncLane /*0b0000000000000000000000000000001*/
)
// => true. SyncLane is not Idle task

isSubsetOfLanes(
  NonIdleLanes, /*0b0001111111111111111111111111111*/
  OffscreenLane /*0b1000000000000000000000000000000*/
)
// => false. OffscreenLane is Idle task

isSubsetOfLanes(
  TransitionLanes, /*0b0000000001111111111111111000000*/
  TransitionLane1 /*0b0000000000000000000000001000000*/
)
// => true. TransitionLane1 is included in TransitionLanes

As mentioned above, isSubsetOfLanes allows you to determine if the corresponding Lane is a subset of the target Fiber.

For example, there is a function scheduleWorkOnParentPath. This function, roughly speaking, is responsible for notifying the upper level parent that the lower level child has a task.

// https://github.com/facebook/react/blob/a8964649bb6332cf1f8d723f81ce97cc5a1886ff/packages/react-reconciler/src/ReactFiberNewContext.new.js#L142
export function scheduleWorkOnParentPath(
  parent: Fiber | null,
  renderLanes: Lanes,
) {
  // Update the child lanes of all the ancestors, including the alternates.
  let node = parent;
  while (node !== null) {
    const alternate = node.alternate;
    if (!isSubsetOfLanes(node.childLanes, renderLanes)) {
      node.childLanes = mergeLanes(node.childLanes, renderLanes);
      if (alternate !== null) {
        alternate.childLanes = mergeLanes(alternate.childLanes, renderLanes);
      }
    } else if (
      alternate !== null &&
      !isSubsetOfLanes(alternate.childLanes, renderLanes)
    ) {
      alternate.childLanes = mergeLanes(alternate.childLanes, renderLanes);
    } else {
      // Neither alternate was updated, which means the rest of the
      // ancestor path already has sufficient priority.
      break;
    }
    node = node.return;
  }
}

Here, node.return is the Fiber of a parent or multiple parents, so you can see that it is a function that updates childLanes by following the path of the parent in order. For example, it can be used to tell the parent when the React.Context is updated in children.

In this function, isSubsetOfLanes is used.

    if (!isSubsetOfLanes(node.childLanes, renderLanes)) {
      node.childLanes = mergeLanes(node.childLanes, renderLanes);
      if (alternate !== null) {
        alternate.childLanes = mergeLanes(alternate.childLanes, renderLanes);
      }
    } else if (

Since node represents parent here, we can see that we are doing something like this: "If parent.childLanes (node.childLanes in the code) is not a subset of the target Lane, update parent.childLanes to the value merged with the target Lane." By doing this, we can move the lanes of children to the parent side. As a result, if you look at fiber.childrenLanes at reconcile time, you will know that the lower layer needs to be re-rendered.

In this way, Lanes make it easy to group multiple tasks together and still determine their priority in a few passes; when reconciliation, we can just refer to / update / merge Lanes and focus on the main algorithm. As a result, an architecture that matches the idea of Fiber and Suspense can be realized.

In addition to Lane, there are several other core PR that will be implemented in React 18 alpha, which are detailed in the following thread.

https://twitter.com/rickhanlonii/status/1402771549808214016

https://twitter.com/dan_abramov/status/1402927593406582787

https://twitter.com/acdlite/status/1402982843962343425

Isn't it amazing to think that after all the design, implementation, verification, and design iterations, a major version upgrade has finally been made since Fiber was announced?

Rewrite React Fiber core algorithm in 300 lines

okmttdhr — Mon, 21 Jun 2021 05:24:52 +0000

Rewrote the React Fiber algorithm.

okmttdhr / my-own-react

Rewrite React Fiber core algorithm in 300 lines with links to the React source code

It's about 300 lines long, but I've tried to re-implement the real React as closely as possible, including the naming and function's scope. The implementation was focused on the following points;

The data structure and algorithm of Fiber
An interruptible unit of work (conceptually same as concurrent mode)
Render and commit phase

Architecture;

I have also commented a link to the React source code, so you can compare it for a better understanding. (For example, in this case, requestIdleCallback is used to implement pseudo-scheduling, but React is using its own Scheduler).

Since there is already a lot of information about the architecture of Fiber, this article will only introduce some pieces of code.

performUnitOfWork

Traverse the Fiber to determine the next unit of work.

// https://github.com/okmttdhr/react/blob/84c06fef8168e779d15cc9450f67888445f7b4f4/packages/react-reconciler/src/ReactFiberBeginWork.new.js#L3206
function beginWork(fiber) {
  const isFunctionComponent =
    fiber.type instanceof Function
  if (isFunctionComponent) {
    updateFunctionComponent(fiber)
  } else {
    updateHostComponent(fiber)
  }

  if (fiber.child) {
    return fiber.child
  }

  let nextFiber = fiber
  while (nextFiber) {
    if (nextFiber.sibling) {
      return nextFiber.sibling
    }
    nextFiber = nextFiber.parent
  }
}

// https://github.com/facebook/react/blob/84c06fef8168e779d15cc9450f67888445f7b4f4/packages/react-reconciler/src/ReactFiberWorkLoop.new.js#L1574
function performUnitOfWork(fiber) {
  nextUnitOfWork = beginWork(fiber)
  if (!nextUnitOfWork) {
    commitRoot()
    completeUnitOfWork()
  }
}

workLoop

Loop until it runs out of work.
When the browser gets busy, stop the loop and come back when it's done.

// https://github.com/facebook/react/blob/84c06fef8168e779d15cc9450f67888445f7b4f4/packages/react-reconciler/src/ReactFiberWorkLoop.old.js#L1567
function workLoop(deadline) {
  let shouldYield = false
  while (workInProgressRoot && !shouldYield) {
    performUnitOfWork(nextUnitOfWork)
    shouldYield = deadline.timeRemaining() < 1
  }
  requestIdleCallback(workLoop)
}

reconcileChildren

Diffing and updating Fiber

// https://github.com/facebook/react/blob/84c06fef8168e779d15cc9450f67888445f7b4f4/packages/react-reconciler/src/ReactFiberBeginWork.new.js#L255
function reconcileChildren(workInProgressFiber, elements) {
  let index = 0
  let oldFiber =
    workInProgressFiber.alternate && workInProgressFiber.alternate.child
  let prevSibling = null

  while (
    index < elements.length ||
    oldFiber != null
  ) {
    const element = elements[index]
    let newFiber = null

    const sameType =
      oldFiber &&
      element &&
      element.type == oldFiber.type

    if (sameType) {
      newFiber = {
        type: oldFiber.type,
        props: element.props,
        dom: oldFiber.dom,
        parent: workInProgressFiber,
        alternate: oldFiber,
        flag: UPDATE,
      }
    }
    if (element && !sameType) {
      newFiber = {
        type: element.type,
        props: element.props,
        dom: null,
        parent: workInProgressFiber,
        alternate: null,
        flag: PLACEMENT,
      }
    }
    if (oldFiber && !sameType) {
      oldFiber.flag = DELETION
      deletions.push(oldFiber)
    }

    if (oldFiber) {
      oldFiber = oldFiber.sibling
    }

    if (index === 0) {
      workInProgressFiber.child = newFiber
    } else if (element) {
      prevSibling.sibling = newFiber
    }

    prevSibling = newFiber
    index++
  }
}

commitWork

Update DOM (Commit phase)

// https://github.com/facebook/react/blob/84c06fef8168e779d15cc9450f67888445f7b4f4/packages/react-reconciler/src/ReactFiberCommitWork.new.js#L1814
function commitWork(fiber) {
  if (!fiber) {
    return
  }

  let parentFiber = fiber.parent
  while (!parentFiber.dom) {
    parentFiber = parentFiber.parent
  }
  const parentDom = parentFiber.dom

  if (
    fiber.flag === PLACEMENT &&
    fiber.dom != null
  ) {
    commitPlacement(fiber, parentDom)
  } else if (
    fiber.flag === UPDATE &&
    fiber.dom != null
  ) {
    commitUpdate(
      fiber.dom,
      fiber.alternate.props,
      fiber.props
    )
  } else if (fiber.flag === DELETION) {
    commitDeletion(fiber, parentDom)
  }

  commitWork(fiber.child)
  commitWork(fiber.sibling)
}

// https://github.com/facebook/react/blob/84c06fef8168e779d15cc9450f67888445f7b4f4/packages/react-reconciler/src/ReactFiberWorkLoop.new.js#L1693
function commitRoot() {
  deletions.forEach(commitWork)
  commitWork(workInProgressRoot.child)
}

Comments and PRs are welcome!

Resources

Micro Frontends Patterns#14: Reading List

okmttdhr — Thu, 28 Jan 2021 09:53:05 +0000

// Detect dark theme var iframe = document.getElementById('tweet-1132493678730252288-827'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1132493678730252288&theme=dark" }

Essentials

Books

Videos

Articles

OSS

Micro Frontends Patterns#13: Build Time Composition

okmttdhr — Thu, 28 Jan 2021 09:50:20 +0000

Build Time Composition assembles Fragments at build time, not at client or server.

Shared libraries

One way to do Build Time Composition is to create shared libraries using npm or similar. In this case, each Micro Frontends will use the shared library. For example, UI components used in the company are provided as component libraries.

We need to consider about how to bundle duplicate code and limit styles' scope. The interface will also need to be carefully designed to maintain consistency across applications.

Also, which team will be in charge of development should be discussed before implementation. For example, there is a distributed development pattern where everyone is a contributor, an OSS pattern where a "platform team" is set up with a main maintainer and reviewer, and a pattern where one team is in charge of all development.

It is important to be careful to make the library meaningful, following "Duplication is far cheaper than the wrong abstraction".

SSG

This is the way to use SSG technology described in the chapter of JAMstack. For example, the following flow can be considered.

In this case, APIzed Fragments are converted to static content at build time.

Bit

Bit is a tool for component-driven development that allows you to easily build, versioning, deploy, etc. from CLI.

For example, you can see which avatar component or nav-item component is being used by which component, so that you can perform appropriate versioning.

One of the advantages of using Bit is that it provides a kind of framework for the development flow of Build Time Composition.

Pros and Cons

Pros

The advantage of Build Time Composition is that it provides SEO and performance advantages without taking server resources into account. It is only with Build Time Composition that you can enjoy the benefits of Server Side Composition while reducing the various runtime considerations.

Cons

Build Time Composition does not allow deployments to be loosely coupled. This is a big disadvantage in terms of Micro Frontends. For example, a library that uses Build Time Composition needs to be deployed after the libraries' updates.

Also, depending on the application, it may be necessary to design the interface in such a way that it does not depend on the Framework.

Summary

With Build Time Composition, we looked at Micro Frontends using the SSG and shared libraries. We would like to consider this as one of the options depending on the use-cases.

Micro Frontends Patterns#12: Server Side Composition

okmttdhr — Wed, 27 Jan 2021 00:55:21 +0000

Server Side Composition, as the name suggests, is a pattern that assembles Fragments on the server side.

Here are some of the architectures which I know.

Layout Server + Fragments Server

Layout Server + Fragments Server is a simple Server Side Composition.

The Fragments Server here means the server that returns the Fragments by each Micro Frontends team, and the Layout Server is the server side application such as Rails, PHP, Node.js, etc. that assembles the Fragments and returns the final HTML, CSS, and JS.

First, let's consider the Node.js Layout Server + Fragments Server.

For example, if there are two Fragment servers, one exposing React components and the other exposing Vue components, the Layout Server can parse and assemble them.

So, what if your existing application is written in a language other than Node.js? In fact, I think that's the pattern in many cases.

In this case, it's difficult to handle framework-specific Fragments, so we'll take an HTML string and assemble the Fragments.

Both of these patterns seem to work well at first glance.

However, let's consider the case where we want to pass the data from the server to the component and then SSR it. In this case, the Fragments server itself needs to have an interface that can receive data and return a response. It is necessary to have some common understanding within the organization. Also, if you want to return HTML string, you need to implement it in such a way that the component is rendered and converted to a string after receiving the data. Versioning should be done well, too. Isn't it getting tedious to do like this?

The Layout Server + Fragments Server pattern is straightforward, but the difficulty increases when you try to deal with a variety of requirements.

Layout Server + Fragment Gateway

The Layout Server + Fragment Gateway pattern is similar to the Gateway Aggregation pattern introduced in previous chapter. The role of the Fragment Gateway here is similar to that of the API Gateway in Gateway Aggregation. It takes care of the access to multiple Fragments, separates the responsibilities from the Layout Server, and unifies the interfaces from Frontend.

Let's look at a example. The following figure shows an architecture using Hypernova for Micro Frontends.

Here, the Layout Server is made of Rails and the Fragment Gateway is made of Node.

1) Layout Server creates data for the server, 2) requests it to Fragment Gateway, 3) then Fragment Gateway pours the data into the component, and finally 4) HTML with the data is returned¹.

The role of the Fragment Gateway is to abstract Fragments as an API from the perspective of the Layout Server, allowing it to become the gateway for handling a wide variety of Fragments as SSR-enabled components. In addition, no matter what framework is used on the Fragments side, the Fragment Gateway can handle it without changing existing server architecture².

The above is the basic architecture of Layout Server + Fragment Gateway. There are several frameworks that can do Server Side Composition with this pattern, including OpenComponents, Podium, and PuzzleJs.

Tailor

Here, I would like to introduce a library called Tailor.

Tailor is not a Layout Server + Fragment Gateway pattern, but rather a more sophisticated Layout Server, with some unique features in terms of assembling Fragments.

In Tailor, you can resolve Fragments by doing the following

<html>
<head>
    <script type="fragment" src="http://assets.domain.com"></script>
</head>
<body>
    <fragment src="http://header.domain.com"></fragment>
    <fragment src="http://content.domain.com" primary></fragment>
    <fragment src="http://footer.domain.com" async></fragment>
</body>
</html>

Each Fragment is requested asynchronously and can be prioritized as primary async.

Streaming

Fragments are delivered as a stream, so you don't have to wait for all Fragments to be completed, which speeds up Time to First Byte.

Assets

Fragments to be SSR need Rehydration, which means we need JS/CSS assets.

Tailor will respond with the asset information in the Link Header. The nice thing about this is that you can tell Tailor which assets to load. For example, consider the following response for an asset with a hash

fragment.ctfvygbh.js

In this case, even if you generate different hashes for different client versions, you can still read the assets that are responded to, making it easier to use a caching strategy.

Summary

Using a library like Tailor that focuses on Layout Server functionality reduces the number of considerations on the part of the Micro Frontends consumer, while optimizing for TTFB and asset management.

Ara Framework

The Ara Framework is based on Hypernova, and provides a CLI and a set of modules for building Micro Frontends. Among them, the architecture of Server Side Composition is unique.

The whole picture is as follows.

For details, please refer to Doc, but here I will just give an overview.

Strangler Pattern

First of all, Author's Medium shows that the Ara Framework is designed with the Strangler Pattern in mind.

For example, imagine a monolithic application built in Rails or Laravel and gradually refactor it into an architecture suitable for Micro Frontends.

(From Microsoft Cloud Design Patterns)

The following is a description based on this assumption.

Nova Proxy

The Nova Proxy is a reverse proxy that sits between the existing application, which takes request from the browser, and render HTML.

The PHP server communicates with the data layer, and when generating the HTML, placeholders are embedded in advance and returned to the Nova Proxy.

The Nova Proxy parses the HTML it receives and requests the data embedded in the placeholders as a payload to the Nova Cluster. Its job is then to replace the placeholders with the returned Fragments. This layer is also responsible for handling fallbacks and timeouts, for example.

Nova Cluster

Nova Cluster is the Fragment Gateway in this chapter.

Nova Cluster receives data from Nova Proxy to multiple Fragments at once. Based on the requests it receives, Nova Cluster queries each Fragment, generate HTML, and returns it to Nova Proxy.

Summary

With this architecture, existing servers can reduce their awareness of Micro Frontends and focus on building the data. It may also be possible to break down the responsibilities, gradually moving the existing rendering logic to the Nova Proxy, and decoupling the Backend layer as an API.

Pros and Cons

Pros

One of the things that Server Side Composition can accomplish is SSR. Another advantage is that it can be implemented in Stream. In addition, by providing a Fragment Gateway, for example, the client no longer has to make multiple requests to Fragments. This kind of performance and SEO requirements may be mandatory for some applications, in which case Server Side Composition will need to be implemented.

Also, if you have an existing monolithic server side application that you want to decompose into microservices, you need to make the Frontend and Backend loosely coupled. As shown in the example of Ara Framework, Server Side Composition can flexibly handle the case where a legacy monolithic application is gradually refactored.

Cons

One of the disadvantages, as you may have noticed, is the increase in complexity. You need to consider an architecture that is not only in Frontend, and since there will be server resources, you will also need to design for availability and scalability. It is always important to be aware of how these will ultimately improve the development efficiency of the organization.

This is also true for Micro Frontends in general, but there is no de facto technology yet. Since the existing systems and the sense of challenges differ from organization to organization, I believe that the situation is such that each company implements the best, and the companies that have the strength makes their software Open Source (therefore, the architecture of the libraries introduced in this chapter varies). It is necessary to understand the design concept of the library or framework, determine whether it fits your company's challenges, and if not, you need to implement it by yourself.

Summary

In this chapter, I introduced Server Side Composition and the architecture of some libraries. I believe that with Server Side Composition, we can adopt a flexible architecture that will be helpful while thinking real-world complex challenges.

hypernova-${client} (in this case hypernova-ruby) can be used to abstract requests to hypernova/server. See GitHub for details. ↩
I'm sure this will be discussed in the case of Microservices as well, but I think the organization needs to have a common understanding of whether to align the frameworks. First of all, it can be seen that it is more natural to have Framework Agnostic as an interface. The fact that each team can select technologies independently is also close to the original idea of Micro Frontends. However, in reality, there is more to think about with different frameworks (complexity of coupling layers, bundle size, reinventing the wheel within the company), and there is also the benefit of being able to share information in a "Guild" style. It is my opinion that you need to think about the use case on the user side and consider which is more suitable. ↩

Micro Frontends Patterns#11: Edge Side Composition

okmttdhr — Mon, 04 Jan 2021 09:21:02 +0000

Edge Side Composition is a technology that combines content at the edge layer, such as CDN.

Edge Side Composition here is assumed to be a process that assembles and renders Fragments at the Edge Side.

Edge Side Includes

The ESI in the previous section can be a kind of Edge Side Composition.

Edge Side Rendering

In this section, SSR running on the Edge Side are called Edge Side Rendering. For example, Edge Side Rendering with Next.js using Lambda@Edge and Serverless Framework, Edge Side Rendering with Cloudflare Workers using a framework called Flareact.

The Edge Side FaaS can take care of the dynamic Backends that the server is usually in charge of, and can also deliver the static content.

Pros and Cons

Pros

As the name suggests, Edge Side Composition does not require any server resources for composition. Since everything is done on the Edge Side, there is no need to prepare and manage a computing environment for a simple rendering server. Also, in terms of latency, since it delivers just static contents on the Edge Side, it will have an advantage over a simple Node server.

There are also advantages in terms of scaling. For example, when using SSR with React, the nature of Node.js can cause CPU-bound. Edge Side Composition is designed for serverless computing environments, so it reduces the need for infrastructure scaling considerations. In addition, AWS Lambda, for example, scales horizontally on a per-request basis, so the possibility of CPU-bound can be reduced as well.

Cons

We will use some kind of FaaS actually. Because it is managed service, its quota can be a disadvantage. For example, in AWS Lambda, the following limitations exist;

Timeout - 15 minutes, 5 seconds for Viewer and 30 seconds for Origin in Lambda Edge
Response size - 6MB, 40KB for Viewer and 1MB for Origin in Lambda Edge
Size of the function itself - 50MB, 1MB for Viewer and 50MB for Origin in Lambda Edge

For example, in terms of function size, it is necessary to compactly package modules related to rendering. Also, when using configuration management tools such as CloudFormation, you need to consider the limit on the number of resources and the design of IaC. Cold start is another point that needs to be considered. Thus, when using FaaS, it will be necessary to investigate and agree in advance whether it will meet the actual application requirements.

If you don't want to be bothered by the above limitations, you might want to consider an architecture such as Fargate + CDN, or scaling with ECS or EKS in the first place.

Summary

Edge Side Composition is a dream architecture that gives JAMstack the weapon of a computing environment, but I think it needs to be used with a good understanding.

Micro Frontends Patterns#10: Edge Side Includes

okmttdhr — Fri, 01 Jan 2021 05:14:45 +0000

Edge Side Includes (ESI) is a technology or a markup language used to assemble content at the edge layer, such as CDN.

Specifically, content is resolved at the Edge Side by writing the following

<html>
  <body>
    This is my fragment: <esi:include src="https://our.fragments.com/fragment.html"/>
  </body>
</html>

ESI is a relatively old technology, the specification was developed by a group of companies like Akamai and Oracle. It's implemented by some CDN vendors like Akamai, Cloudflare, Fastly, Varnish, and others. In the context of Micro Frontends, this is used to compose Fragments.

Pros and Cons

There are a limited number of CDN vendors that can be used, so you need to consider whether you can tolerate that before implementing. And you need to be careful about ESI's resource acquisition logic differs depending on the vendor.

Also, since ESI is a simple specification, it may not be flexible. For example, data retrieved on the server side cannot be passed to Fragments on the Edge. Furthermore, it is difficult to render applications that require CSR like SPA.

From a development point of view, local development can be tricky. In practice, you may need to consider a wrapper such as nodesi. (Personally, I also don't like the fact that the application logic depends on the Edge Side specification).

However, the fact that it can be written simply and has minimal features such as Fallback and Timeout is an advantage. It is also attractive that you don't have to think about the server while you don't need to care about Fragments on client-side code. Also, since you can cache a part of UI, ESI is unique in that you can take a flexible caching strategy, such as when you want to cache only static content on a screen where dynamic and static content live together.

Summary

In this article, we have shown how ESI can be used to compose Fragments on the Edge Side. Although the simplicity of ESI makes it not very flexible, it is a good option if it fits your use case.

Micro Frontends Patterns#9: Client Side Composition

okmttdhr — Wed, 30 Dec 2020 03:14:57 +0000

The next pattern is called Client Side Composition, but before that, let's talk about the concept of Fragments.

What are Fragments?

Fragments is a element that builds a page in Micro Frontends.

The above is borrowed from micro-frontends.org, and each of these different colored elements is a Fragment. This is pretty close to what we imagine the name Micro Frontends.

Fragments are not just UI components, but rather elements which provide some functionality for the business domain. In the example above, there are Team Product, Team Checkout, and Team Inspire, with separate development teams and deployments, each of which is a vertical decomposition.

Fragments are not applications on their own, so there must be a composition layer somewhere. In the example above, Team Product is the owner of the "Product Detail Page", which is combined with other Fragments. Client Side Composition, which we will now discuss, is one of those composition patterns.

Fragments can be called in different ways depending on the Micro Frontends library. For example, Podium uses Podlets, OpenComponents uses Components, and PuzzleJs and Tailor use Fragments. In this article, I will refer to the aforementioned concepts as Fragments.

What is Client Side Composition?

Client Side Composition is one of the patterns that combine Fragments on client-side, and as the name suggests.

It uses HTML, CSS, and JavaScript to render Fragments at runtime. Let's look at some concrete examples.

Web Components

This is a pattern that uses Web Components.

Prepare the following markup, and JavaScript on the client-side render the UI.

<my-fragment></my-fragment>

class MyFragment extends HTMLElement {
  connectedCallback() {
    this.innerHTML = `<h1>Hello world</h1>`;
  }
}

customElements.define('my-fragment', MyFragment);

Framework Specific

This is the pattern of using some framework or library, for example, React can render Fragments for markup like this, which is not so different from Web Components.

<div id="app"></div>

const MyFragment = () => <h1>Hello, world</h1>;
React.render(<MyFragment />, document.getElementById('app'));

Using the library

There are several libraries that enable Client Side Composition, most of them are in the style of using Fragments in the App Shell, and some of them provide CLI and so on to make the development more efficient.

Pros and Cons

Client Side Composition is a simple Micro Frontends. It can be used by simply loading markup and JavaScript, and can be achieved with familiar web standard technologies. (Web Components has the disadvantage that there is no standard way to do SSR, so it is difficult to adopt if you want to do SSR in the future).

However, since FCP and TTI tend to be large, performance considerations such as Lazy load are necessary. Also, if each Fragments uses a framework, you need to be careful about the bundle size. In some cases, libraries that provide an App Shell layer may be considered to cover such details.

Summary

We have seen the Composition pattern called Client Side Composition. I think the runtime composition is easy to understand and is a technique that Frontend engineers are familiar with.

Micro Frontends Patterns#8: Unified SPA

okmttdhr — Tue, 29 Dec 2020 03:32:26 +0000

Unified SPA is similar to Linked Application, but it navigates multiple SPAs.

In the case of a simple hyperlink transition, it will be the same as a Linked Application. The transition between SPAs will be server-side rendering, so there will be a round trip.

There is another pattern for Unified SPA. It is the pattern of creating an App Shell layer that binds the SPAs together.

In this case, since the client-side rendering between SPAs is done in the App Shell layer, the performance overhead, which is one of the disadvantages of Linked Application, is reduced.

This can be achieved by using a library such as single-spa called meta-framework. An example code for the configuration part is shown below, which combines separately deployed applications.

import { registerApplication, start } from 'single-spa';

registerApplication(
  'app2',
  () => import('@my-company/app2/main.js'),
  (location) => location.pathname.startsWith('/app2'),
  { some: 'value' }
);

registerApplication({
  name: 'app1',
  app: () => import('@my-company/app1/main.js'),
  activeWhen: '/app1',
  customProps: {
    some: 'value',
  }
});

start();

If you are interested in other libraries, please refer to Reading List which will be the last section of this series.

Pros and Cons

Because it is an SPA, the interactivity of the Frontend will be improved compared to Linked Application, and the fact that you can achieve Micro Frontends by simply merging SPAs together is also a good thing. It is also possible to create common parts using the Parcels mechanism of single-spa.

One of the disadvantages of Linked Application is that it tends to be a single point of failure in the application layer; if there is a bug in the App Shell layer, it will spread to the entire application, and the impact of version upgrades will be large.

Summary

We looked at the Unified SPA pattern, which is an extension of the Linked Application pattern, and while introducing an App Shell layer has its disadvantages. As a simple Micro Frontends, this is the first one you can consider adopting.

Micro Frontends Patterns#7: Linked Application

okmttdhr — Sun, 27 Dec 2020 02:03:48 +0000

Linked Application is a simple architecture that navigates multiple applications with hyperlinks.

A common example is a standalone user account application that is linked from multiple applications. In this case, services related to a user account are done only in the account application, and other applications hyperlink to it from a header, user menu, etc. "Google Account" can be an example.

It is also possible that applications can be in the same domain. In this case, each page has its own independent development team and deploy pipeline.

Linked Application is one of the easiest Micro Frontends to get started with, and I'm sure we've all seen it at least once.

iframe

Although not a Linked Application, we can accomplish Micro Frontends with iframes, as Spotify does. Compared to Linked Application, you can use it more flexibly by embedding it in a part of the page, and since it is a old technology, it is supported by all browsers. However, there are some issues that need to be considered, such as performance overhead, SEO considerations, accessibility, and motivation of engineers.

Pros and Cons

Pros

The main advantage of this pattern, which seems not to be cool, is that it allows applications to be loosely coupled. The fact that the applications are isolated also means that each system is robust. If one application goes down, the others are unaffected.

Cons

On the other hand, there is the problem of communication difficulties due to the isolation. As the name suggests, applications can only communicate with each other through "links". Also, although it is a simple architecture, it makes it difficult to manage common parts such as headers, and it also creates redundancies such as duplicate development for each team. The hyperlink experience is also not great for users.

Summary

Linked Application has been one of the most common patterns for a long time because it is quick to implement, but it is important to understand its drawbacks.

Micro Frontends Patterns#6: Isomorphic JavaScript

okmttdhr — Wed, 23 Dec 2020 00:29:10 +0000

Isomorphic JavaScript (Universal JavaScript) refers to JavaScript or JavaScript applications that work on both the client and server.

This chapter show you some use cases and technologies.

Server Side Rendering

A typical example is Server Side Rendering (SSR) in React applications, which uses ReactDOMServer to generate markups on the server side and return dynamic views from the server side.

This solves the performance bottleneck of Client Side Rendering, SEO optimization and OGP issues. It also allows the use of Virtual DOM libraries such as React as "templates", avoiding the traditional inefficient client side programming with template engines.

SSR in this context includes a technique called Rehydration. The ability to do rehydration means that, for example, Client Side Rendering is also possible. The SSR application is displayed for initial rendering only, followed by rehydration on the client side, and Client Side Rendering thereafter.

BFF

BFF, or Node.js as an API Gateway layer, can be considered as an extension of Isomorphic JavaScript as SSR. Basically, let Backend Microservices do the CPU-heavy processing, and BFF communicates with them via API. I think it fits well as a BFF layer ¹, partly because ~~Node.js doesn't have very nice ORM~~ I personally don't like Node.js ORM as much as those in other languages ².

As I mentioned in the Microservice Architecture chapter, the Gateway layer needs some work to keep it simple. Node.js's ease of implementing asynchronous & non-blocking I/O and TypeScript's strong type support are not bad for a language that runs on this layer.

Next.js

SSR had some technical complications. For example, there are processes for fetching data that you want to run only on the server side, and processes for rehydrating data in a state management layer such as Redux.

Frameworks such as Next.js and Nuxt.js have emerged as technologies to cover these troublesome issues. They were not just for SSR, but they had an impact at the time simply because they wrapped up the difficulties of SSR.

In addition, API route in Next.js allows for backend implementation, so we can expect to see uses such as BFFs and endpoints for SSG, which I mentioned in the JAMstack chapter. The fact that you can use universal bundling with almost zero configuration is also attractive.

It is also unique in that it can be used to build a hybrid of SSR, SSG, and Incremental Static Regeneration. For more information, please visit https://nextjs.org.

Pros and Cons

Pros

The fact that the Gateway layer can be developed in one language and the "frontend" of the application can be taken care of using only JavaScript will reduce switching costs and will be effective in team development of distributed systems. It is also good at handling large numbers of requests due to the aforementioned asynchronous and non-blocking I/O nature.

Although it not about the Web, it also has high portability as a program, in that it can run on relatively any device, anywhere. The client is implemented in JavaScript, and can often be used as a set.

Cons

Rather than the disadvantages of Isomorphic JavaScript itself, you need to understand the weak points of Node.js and JavaScript. For example, one of the biggest ones is the aforementioned CPU-heavy characteristics.

As for JavaScript as a language, I feel that it has a complex build process and ecosystem. In today's JS world, considering TypeScript, testing, etc., building is a prerequisite, and considering understanding and using the surrounding ecosystem and compiler specifications, it is a relatively complex world compared to other languages. TypeScript is certainly wonderful, but I think the complexity of it is difficult to understand for different language people.

And it is too free as a language, that can be both an advantage and a disadvantage. JavaScript is a multi-paradigm language that can be written in many different ways, and some engineers may find it difficult to implement asynchronous processing or package structures.

Summary

Isomorphic JavaScript offers the choice to provide the entire Frontend of an application with JavaScript. When used in the right way for the right use case, it has proven to have advantages that are second to none to other languages.

I don't like NoSQL as an escape either. ↩
I have only used Sequelize and TypeORM. ↩

Micro Frontends Patterns#5: Microservice Architecture

okmttdhr — Tue, 22 Dec 2020 00:46:33 +0000

The Microservice Architecture is an architecture that combines applications with the following characteristics

Loosely coupled, Highly cohesive
Can be deployed independently
Bounded by a business domain
Accessible via some communication protocol
Developed by an autonomous team

If you want to know more about Microservice Architecture, please refer to the book Building Microservices.

In this section, I'll show you some of the patterns in communicating with Microservices, focusing on the Frontend.

Service Discovery

Service Discovery is a pattern that creates an abstraction layer of multiple interfaces on the Frontend side and interacts with the Backend.

The pattern is to create a layer that abstracts multiple interfaces on the Frontend and interact with the Backend.

For example, you can imagine JSON like the following. In practice, you may want to create a layer of abstraction for the request, such as a Repository Pattern.

{
  "micro_service_foo": {
    "v1": "https://api.foo.service.com/v1",
    "special": "https://api.foo.service.com/special"
  },
  "micro_service_bar": {
    "v1": "https://api.bar.service.com/v1",
    "v2": "https://api.bar.service.com/v2"
  }
}

One of the nice things about Service Discovery is that you can freely combine them in the Frontend; in the context of Micro Frontends, multiple components may each request different Microservices, and it may be convenient to change them freely in the App Shell layer.

We can also get JSON returned by the API.

In this case, it is easier to do version upgrades or changes on the server side. This pattern is inspired by Client-side service discovery used in Backend Microservices.

Gateway Aggregation

Gateway Aggregation is a pattern that combines requests to multiple Microservices into a single endpoint (API Gateway) (from Microsoft Cloud Design Patterns.

The abstraction layer at the client, as it was in Service Discovery, is gone and simplified, and performance overhead is improved.

Backends for Frontends

Backends for Frontends (BFF) is a pattern that is similar to Gateway Aggregation, but provides an interface for each specific Frontend application (from Microsoft Cloud Design Patterns).

With Gateway Aggregation, we had the following problems.

Different data that different Frontend teams wants causes the data manipulation process in Frontend.
Data that is only used by one application can be added to the interface, which can be redundant.
Difficulty in updating Backend APIs by considering all platforms.

The goal of this pattern is to provide a more application-specific interface, so that the interactions are optimized for each of them.

The case of Netflix

Netflix is using GraphQL Federation for their API Gateway.

How Netflix Scales its API with GraphQL Federation | Netflix TechBlog

For more information on GraphQL Federation, please see the following

Netflix is facing the following problems with a simple API Gateway

Lack of domain knowledge on the part of the Gateway team
The connection to the Gateway had to be done manually.
A lot of things to do for the Gateway team due to the above

In order to solve this problem, they have taken an approach to merge each schema with GraphQL Federation and reduce the scope of responsibility of Gateway. In the end, the architecture became the following "federated gateway architecture" to realize One Graph API.

Each Microservices team, which is familiar with the domain, provides its own schema, and the Gateway team is responsible for managing the Graph. I feel that this leads to the topic of "Who develops the BFF?" which will be discussed later.

Pros and Cons

One of the topics of creating an API Gateway is "Who will develop the API Gateway?". For example, if you are creating a BFF, it seems correct for the Frontend engineer to have a responsibility of it, but in reality, you will consider the engineer's skills and development costs.

Another topic is the common function; in a BFF, only application-specific logic should be placed, but there may be an increase in duplicated code in multiple BFFs. For these, the basic idea is Duplication over the wrong abstraction, but how should it be extracted? Should we really extract them? Which team will be responsible for it? These will be a point of discussion. It is also necessary to design it so that it is loosely coupled with the Microservices it calls.

In the context of Micro Frontends, we could be talking about, at what level do you want to use the API Gateway? or should use Service Discovery?

Summary

In this article, we introduced how to interact with Microservices from the Frontend in the recent situation.

Instead of interacting with multiple Microservices directly, there is a trend to abstract the complexity by providing one interface for one Frontend app.