pagee

pagee-微前端引擎 (draft)

灵感来源：k8s的编排思想及微服务架构思想，主要特性包含

• 框架无关，无论你之前的前端框架是react, vue还是angular都可以很方便的用pagee把他们编排到一起。
• rpc，pagee提供了通用通信层。app之间的通信更接近于微服务的rpc方式，pagee的runtime提供了通信的抽象层，可以是内部事件，也可以是与后端API的通信，但在使用方式上达到了一致。

为什么微前端

随着微服务架构体系的渐亦成熟，越来越多的公司转向微服务架构并从中受益。微服务的出现首先就是解决了单体应用的很多痛点，所以在前端工程领域这些思想成面的东西也会受用。

• Faster Builds The larger a project becomes, the longer it can take for that project to build. While bundlers such as Webpack and Parcel have went to great lengths to improve the performance of bundling through use of multiple threads and caching, in my opinion, it’s only a stop-gap measure for a more fundamental problem. Even with those performance improvements, as your app continues to grow, your app will progressively become slower to build. Remember that without a good developer experience, it’s difficult to provide a good user experience.

By splitting your app into several different projects, each with their own build pipeline, each project will be very quick to build, regardless of how your system grows. The continuous integration system would also benefit from this, as each project can be parallelised and built indepedently and finally concatenated together at the very end.

• Dynamic Deployments In my opinion, one of the coolest features about micro-frontends, is the ability to deploy new features without the need to recompile anything else, including the runtime. If you have an existing system, rather than shipping and re-installing an entire system, you only need to ship and install the newest feature. This can be incredibly powerful, and opens up many new distribution possibilities. For example, if you want to license specific features of your system, you can split those features off into separate installers.

• Parallelising Development By splitting your UI into separate projects, this opens the possibility of having multiple teams working on the UI. Each team can be responsible for one feature of the system. One team for example could work on the phone app, while another team can work on the contacts app. Each team can have their own Git repositories, and can run deployments whenever they want, with their own versioning and changelogs.

For the most part, these teams don’t need to know anything about each other. There still however needs to be a point of integration between these two apps. Each team needs to define and guarantee backwards compatibility on a public API. This API is typically implemented through the use of the URL.

pagee的设计思想

借鉴了k8s的一部分编排思想，在k8s中最小的调度单位不是container而是pod,这样解决了很多复杂部署场景下的问题，pagee在调度层面添加了page抽象，page是一个具有完整生命周期的抽象层，可以想象为一个大的容器，就好比当前的整个屏幕内容，page要解决的才是加载app和处理页面layout路由相关的东西。通过更高的角度把这些抽象出来后，我们不需要在关注某个app具体使用的是什么前端框架，我们只关注在调用交互的过程中，我们需要提供哪些标准数据，比如根节点，我们需要调用哪些接口，比如mount(app, ‘root_node’)。_大多前端框架都有自身的通信机制和数据流。在page层面我们不需要关注内部的通信，我们需要关注的是跨app之间如何更好的通信，所以这里我们也借鉴了微服务架构中的一些思想，pagee在runtime层面提供了一个rpc通道，应用间通过标准rpc通道来相互通信。

关键组件

• runtime
• page
  • preloader

加载预处理资源,

• appLoader

加载应用资源

• rpc

组件的定义

通过loader加载过来的微前端组件需要满足一些必要因素，从宏观上来说，我们应有必要的通用抽象如下：

• 入口
  • props
• 生命周期
  • before
  • mounted
  • rendered
  • after
  • unmounted
• 自管控的render体系，包括css样式及DOM结构
• 会话层

runtime

加载器

控制器

命名空间

组件插槽

分发容器

参考

https://micro-frontends.org/ https://medium.com/@PepsRyuu/micro-frontends-341defa8d1d4 https://martinfowler.com/articles/micro-frontends.html