回答这个问题之前，我们先来看下什么是 BigPipe，以及什么是微前端。

BigPipe

BigPipe 最早上 FaceBook 用来提升自家网站性能的一个秘密武器。
其核心思想在于将页面分成多少小的构件，我们称之为 pagelet。
每一个构件之间并行实行。

那么 BigPipe 做了什么？和传统办法有什么不同呢？我们知道浏览器处理我们的 HTML 文档以及个中包含的 CSS，JS 等资源的时候是从上到下串行实行的。
如果我们把浏览器处理的过程划分为多少阶段（stage），那么这些阶段之间有着明显的韶光先后关系。
那么我们能不能将其并行化，从而减少韶光呢？这便是 BigPipe 的基本思想。

bigpipephpBigPipe和微前端 JavaScript

话不多说，我们通过一段代码来帮助大家理解,比如你的项目首页是 home.html，大概这样子：

<!DOCTYPE html><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>

浏览器首先加载过来便是一个占位元素，这部分没有 JS 和 CSS，只有 HTML 部分，因此会很快。

之后我们逐步添补pagelet1,pagelet2, pagelet3,在用户看来，便是一种“渐进式渲染”的效果。

做事端代码大概是：

const app = require('express')();const fs = require('fs');// 仿照真实场景function wirteChunk(content, delay, res) { return new Promise(r => { setTimeout(function() { res.write(content); delay); })}app.get('/', function (req, res) { // 为了简化代码，直接同步读。
强烈不建议生产环境这么做！
res.write(fs.readFileSync(__dirname + "/home.html").toString()); const p1 = wirteChunk('<script>BigPipe.render("#pagelet1","hello");</script>', 1000) const p2 = wirteChunk('<script>BigPipe.render("#pagelet2","word");</script>', 2000) const p3 = wirteChunk('<script>BigPipe.render("#pagelet3","!");</script>', 3000) Promise.all([p1, p2, p3]).then(res.end)});app.listen(3000);

从这里我们可以看出，BigPipe 不是框架，不是新技能。
我们只须要按照这样做就行了。
这对付页面可以细分为多个块，块之间关联不大的场景非常有用。
如果还是不太明白，可以看下这篇文章 -https://www.facebook.com/notes/facebook-engineering/bigpipe-pipelining-web-pages-for-high-performance/389414033919/

说完了 BigPipe，我们再来看一下微前端。

微前端

和后端微做事类似，“微前端是一种架构风格，个中浩瀚独立交付的前端运用组合成一个大型整体。
”

如果你想做微前端，一定要能够回答出这 10 个问题。

微运用的注册、异步加载和生命周期管理；微运用之间、主从之间的机制；微运用之间的安全隔离方法；微运用的框架无关、版本无关；微运用之间、主从之间的公共依赖的库、业务逻辑(utils)以及版本怎么管理；微运用独立调试、和主运用联调的办法，快速定位报错（发射问题）；微运用的发布流程；微运用打包优化问题；微运用专有云场景的出包方案；渐进式升级：用微运用方案平滑重构老项目。

这里有一篇文档，差异与别的微前端文章的点在于其更加靠近规范层面，而不是结合自己的业务场景做的探索。
这篇文章来自于阿里团队。

文章地址： https://mp.weixin.qq.com/s/rYNsKPhw2zR84-4K62gliw

还有一篇文章也不错，一并推举给大家 - https://mp.weixin.qq.com/s/DVkrV_KKE9KaGSeUSenc6w

微前端中有一个主要的须要办理的问题是子系统之间的路由。
而我们的 BigPipe 如果被当作一个个子运用的，那不便是微前端中的一个点么？BigPipe 也好，微前端也好，都是一种观点，一种辅导思想。
微前端是不限于技能栈的， 你可以利用传统的 ssr，也可以利用 csr，也可以利用当代 csr + ssr 等，框架也可以五花八门。
如何将这些系统组合起来，并且能够井井有条地进行互助完成一个完全的运用？这是微前端所研究和要办理的问题。

对付微前端，我们隔离各个运用的办法有几种：

iframe类似 bigpipe 这种客户端异步加载技能web-components

不管采取哪种办法，我们的大体逻辑都是：

先加载主框架异步加载各个子运用

只不过加载子运用，我们可以通过 iframe 去加载，也可以利用 web-component 去加载，也可以利用类似 bigpipe 的办法分段并行加载。
我们乃至可以将这几者进行结合利用。
而 iframe 和 web-compoents 顺带办理了诸如 js 和 css 等隔离的浸染，而 bigPipe 只是对资源加载的一个有效掌握，其本身并没有什么分外含义，更不要说诸如 js 和 css 等隔离浸染了。

事物关联

当前端有了 Nodejs 之后，我们创造可以做的事情变多了，除了 BigPipe，我们又去做 ssr，又要做 graphql，还要做微前端，海报做事，AI 等等。
当你从大的视角看的时候，会创造这些技能或多或少都有交集，比如我刚才提到的 ssr。
我们知道 ssr 中有一点便是我们先返回给用户一个有内容的 html，这个 html 在做事端天生，由于在做事端天生，因此只有样式，没有绑定事宜，所往后续我们须要在客户端合成事宜。
如果将上面 BigPipe 的代码拿过来看的话，会创造我们的 html markup 可以看作做事端渲染内容（可以是直接写去世的，也可以是做事端动态天生的）。
之后我们输出后续 pagelet 的 JS 代码到前端，前端连续去实行。
基于 BigPipe 我们乃至可以掌握页面优先级显示。
我们再连续去看的话， BFF 常见的一个功能“合并要求”在这里扮演了什么样的角色？大家可以自己想一下。
当你不断从不同角度思考问题，会创造很多东西都有关联。
每一个技能背后每每都会落到几个基本的事理上。
理解技能初始产生背后办理的问题对付节制一个技能来说非常主要。