You may have heard of BigPipe, a technology that is more than a decade old, and BigPipe is often mentioned in conjunction with “performance tuning.” Microfrontend is another technology that has been around for a long time, but has only become more popular in recent years. At present, the biggest problem that micro front-end can solve is probably legacy system transformation. We can integrate systems built by new technologies with systems built by old technologies, and build, publish, and run with no interference from each other. So what does BigPipe have to do with microfronds, and why do I want to put the two together?

Before we answer that question, let’s take a look at what BigPipe is and what a micro front end is.

BigPipe

BigPipe was one of FaceBook’s first secret weapons to improve the performance of their site. The idea is to break the page up into small pieces, called pagelets. Each component executes in parallel.

So what did BigPipe do? How is it different from the traditional way? We know that browsers process our HTML documents and the CSS, JS and other resources they contain sequentially from top to bottom. If we divide the browser process into stages, there is a clear chronological relationship between these stages. So can we parallelize it to reduce time? This is the basic idea of BigPipe.

Without further ado, let’s use a bit of code to help you understand. For example, if your project’s home page is home.html, it looks something like this:


      
<html>
  <head>
    <script>
      window.BigPipe = {
        render(selector, content) {
          document.querySelector(selector).innerHTML = content; }};</script>
  </head>
  <body>
    <div id="pagelet1"></div>
    <div id="pagelet2"></div>
    <div id="pagelet3"></div>
  </body>
</html>
Copy the code

The first thing the browser loads is a placeholder element, which has no JS and CSS, just HTML, so it’s fast.

Then we slowly fill in pagelet1, Pagelet2, and Pagelet3, which, from the user’s point of view, is a “progressive rendering” effect.

The server code looks like this:

const app = require('express') ();const fs = require('fs');

// Simulate a real scene
function wirteChunk(content, delay, res) {
    return new Promise(r= > {
        setTimeout(function() {
            res.write(content);
        delay);
    })
}

app.get('/'.function (req, res) {
  // To simplify the code, read directly. This is strongly not recommended for production environments!
  res.write(fs.readFileSync(__dirname + "/home.html").toString());

  const p1 = wirteChunk(''.1000)
  const p2 = wirteChunk(''.2000)
  const p3 = wirteChunk(''.3000)

  Promise.all([p1, p2, p3]).then(res.end)

});

app.listen(3000);
Copy the code

From this we can see that BigPipe is not a framework, not a new technology. We just have to do that. This is useful for scenarios where the page can be subdivided into blocks with little correlation between them. Bigpipe – Pipelining – Web – Pages -for High-performance if you still don’t understand

With BigPipe out of the way, let’s look at the micro front end.

Micro front-end

Similar to back-end microservices, “a microfront-end is an architectural style in which a number of independently delivered front-end applications are combined into a large whole.”

If you want to do a micro front end, you must be able to answer these 10 questions.

  1. Registration, asynchronous loading, and lifecycle management of microapplications;
  2. Message mechanism between microapplications and between master and slave;
  3. Security isolation measures between microapplications;
  4. The framework and version of microapplications are independent.
  5. How to manage the libraries, business logic (utils) and versioning of common dependencies between microapplications and master/slave;
  6. Micro-application independent debugging, and the main application of joint debugging, fast positioning error reporting (transmission problems);
  7. Microapplication release process;
  8. Microapplication packaging optimization problem;
  9. Package outputting scheme for micro application private cloud scenarios;
  10. Incremental upgrade: Smooth refactoring of old projects with microapplication solutions.

Here is a document that differentiates it from other micro front end articles in that it is closer to the specification level rather than exploring its own business scenarios. This article is from Alibaba team.

The article addresses: mp.weixin.qq.com/s/rYNsKPhw2…

There is also a good article that I recommend – Micro-front-end architecture in the era of big front-end: incremental upgrades, code decoupling, standalone deployment

An important problem that needs to be solved in the micro front end is routing between subsystems. If our BigPipe is treated as a child application, isn’t that a point in the micro front end? BigPipe, or micro front-end, is a concept, a guiding ideology. The micro front end is not limited to the technology stack. You can use traditional SSR, CSR, modern CSR + SSR, etc. The framework can also be varied. How do you put these systems together and collaborate methodically to create a complete application? This is the problem that the micro front end studies and solves.

For the micro front end, we can isolate applications in several ways:

  1. iframe
  2. Client-side asynchronous loading techniques like Bigpipe
  3. web-components

Either way, the general logic is:

  • Load the main frame first
  • Load each child application asynchronously

We can use iframe to load the child application, web-component to load the child application, or we can use bigpipe to load the child application in parallel. We can even combine them. While Iframe and Web-Compoents conveniently address isolation functions such as JS and CSS, bigPipe is just an effective control over resource loading and has no special meaning in itself, let alone isolation functions such as JS and CSS.

Things associated

With Nodejs on the front end, we have a lot more things to do. Besides BigPipe, we have to do SSR, graphQL, micro front-end, poster service, AI, etc. When you look at it from a larger perspective, there’s more or less overlap between these technologies, like SSR that I just mentioned. We know that one of the things in SSR is that we first return to the user an HTML with content. This HTML is generated on the server side. Since it is generated on the server side, there is only style and no binding event, so we need to synthesize events on the client side later. If you take a look at the BigPipe code above, you’ll see that our HTML markup can be considered server-side rendering (either written dead or dynamically generated by the server). We then output subsequent Pagelet’s JS code to the front end, which continues to execute. With BigPipe we can even control the page priority display. Looking further, what role does “merge requests”, a common BFF feature, play here? You can think about it for yourself. When you keep thinking about things from different perspectives, a lot of things connect. There are a few basic principles behind each technology. Understanding the problems solved behind the initial emergence of a technology is very important to mastering a technology.