Improving scalability and agility is rarely a top priority in any legitimate front-end development team. When working with large, complex products, how do you ensure fast and frequent delivery of both back-end and front-end functionality? Breaking down the front-end monolith into many smaller parts like the back-end seems to be the answer. When executed properly, micro frontends can increase the effectiveness and efficiency of your team. That's it.

The idea behind micro frontends is to treat a website or web application as a composition of functionality owned by independent teams. Each team has a different business area or task that it cares about and excels at. The team is cross-functional, developing its functionality end-to-end, from the database to the user interface.

Breaking down larger problems into smaller ones to increase agility, reusability, and scalability has always been one of the holy grails of IT, and the progress made in this area over the past two decades has been astounding. However, new constraints continue to emerge with larger and larger code bases. Some of the best minds in the industry have been grappling with this challenge, trying to address it from a technical and organizational standpoint. Microservices architecture is definitely still the closest to solving it so far.

In this article, you will learn:

How microservices architecture and micro-frontends work;
what are their greatest strengths;
What requirements must be met when implementing micro frontends;
what technologies or methods are available to you;
and how each of these solutions compares to each other.

Microservice Architecture and Micro Frontends - what they solve and how they work

Microservice architecture promises:

Easier to build and maintain applications
Improve team productivity
Flexibility in using technology
scalability

The solution is to break down large systems into fine-grained, loosely coupled services organized around well-defined business capabilities. Each service is then small enough to be developed by a single development team, and can be quickly adjusted to new business needs and deployed without breaking the rest of the system.

The danger with this approach is that the system will be broken down into many unrelated applications. While this is fine for developers to handle, it's not what users expect from the system; most people don't like having lots of small apps to do their work. Therefore, what was broken down for this process had to be reassembled into the user interface.

put the pieces back together

A common approach is to build a single front-end layer between users and microservices. For every system of importance, a large front-end codebase threatens the benefits of a microservices architecture. This is where micro frontends come in.

The basic idea of micro frontends is very simple - the user interface is composed of multiple fine-grained parts organized around clearly defined business capabilities. Each part is then small enough to be developed and owned by a vertically structured team. Having a front-end and back-end team builds a truly self-sufficient feature team.

Unfortunately, however, micro-frontends pose the same challenges that make microservices difficult to implement. Also, any shortcuts can affect user experience in a negative way. Consistency, security, interoperability, performance, scalability, and ownership must be ensured to ensure a seamless user interface.

Although different micro-frontend approaches address various problems, none of them yet covers them all. But before we dive into the details of these different approaches, let's take a closer look at the main motivations for choosing micro frontends, and their pros and cons compared to monolithic approaches.

Explain the 3 major advantages of micro frontends

Micro Frontends Advantage #1: Scalable Team Setup

3 Different Frontend Approaches and Their Impact on Team Organization
There are many good reasons for choosing a microfrontend approach, but one of the most important (if not the most important) comes from a scalable team setup.

At least three possible front-end architectures can be identified that affect the organization of development teams: monolithic front-end and back-end, monolithic front-end with back-end microservices, and micro-frontends. Below, we describe the consequences of each team organization.

Monolithic front-end and back-end

A common approach to building solutions that require a front-end and a back-end is to split the project horizontally and communicate between these layers through REST APIs.

If the system is small enough to be developed by a team, the best option is to keep the architecture simple. You can do this by creating a Single Page Application (SPA) frontend and connecting it to the backend through a REST API. Then adjust your team setup based on the amount of work required for each tier.

Good practice is to make sure your code is well structured from the start, and when your solution grows, you can bring in another team or two without rebuilding it.

But the limitations of this architecture are obvious: the more a team modifies the code base, the more coordination and integration is required, which paralyzes product development.

Monolithic frontend with backend microservices

Especially in large enterprises, the need for additional development teams often starts on the back end. Most systems require a lot of business logic. For example, they require processing that cannot be done on the browser side, or complex integration with legacy systems. In these cases, a cross-functional team is no longer enough.

The first step for most companies to scale their architecture is to vertically split the backend codebase to address complexity. The front-end is assigned to a dedicated front-end team, while the rest of the work is split among the various back-end teams. As a result, backlog items are broken down into chunks and delivered by different teams. These teams then resolve dependencies either through contract negotiations or — in a more agile approach — through a large backlog of programs.

The biggest challenge with this approach is managing these dependencies and synchronizing releases. Testing also becomes cumbersome as you need to wait for all the individual pieces to reach the test environment in order to verify it.

It gets even more complicated when the solution has to embed functionality from different product backlogs (which happens quite often).

On a larger scale, this approach requires a lot of management. Routine deployment is nearly impossible. That's why developers and architects working in large enterprises with complex front-ends seek solutions for ultimate vertical scaling, adding a front-end to their already game-changing microservices architecture - micro-frontends.

micro frontend

In order to quickly develop, test, and release their features, teams need to be able to work without depending on other teams. Micro frontends can achieve the same promise of backend microservices in the user interface area, and can apply the same principles that support independent teamwork.

In this setup, the front-end and back-end domains are tightly coupled because the requirements come from one Product Backlog. Again, one team can deliver the entire feature in one simple architecture. If executed properly, this should not affect the user experience.

In order to execute it well, micro frontends bring about similar problems known to many backend microservices, which must be solved. Otherwise, users may still perceive or experience the system as a patchwork of different characteristics.

Micro Frontends Advantage #2: Freedom of Technology Choice

In addition to creating a scalable and independent team setup, the micro frontend approach also helps in dealing with the large number of technologies applied to the frontend. Each quarter brings new ideas on how to develop user-facing parts of the system. Many times new versions of frameworks are not even backwards compatible, which means that each version is effectively a separate framework.

One of the advantages of microservices architecture is the freedom to choose the technologies used. When the user interface is split into independent modules, front-end developers can enjoy the same freedom - at least to a certain extent.

Micro Frontends Advantage #3: Elasticity

The real cost of any system is not well reflected in the initial development cost of the code base, but in maintenance. The purpose of the endless spiral of code refactoring and system refactoring is to keep introducing feature changes at the same pace as they started.

The micro frontend architecture makes the code base more resilient by introducing the following constraints:

Isolate the impact of changes;
prevent code coupling;
And preserve the schema over time.

These constraints prevent uncontrolled dependencies, limit code reuse, and enforce service boundaries.

No more uncontrolled dependencies

Large applications developed over many years are inevitably full of code dependencies that are difficult to track and maintain. Developers working under time-to-market pressure, or simply trying to optimize the way they work, create many uncontrolled dependencies between different parts of the code. It always seems like a good idea to reuse some business logic, cached data, or resource pools when introducing new dependencies. What happened later was an unforeseen consequence of this shared functionality change.

This dependency is easily avoided by separating the codebase into several disconnected parts. Due to the natural boundary between the two, it is impossible for one micro frontend to reuse existing functionality of other micro frontends. Therefore, any unintended side effects of changes are limited to one micro frontend.

limited code reuse

The generally followed principle of Don't Repeat Yourself (DRY) aims to limit the size of the code base, thereby reducing the possibility of errors. On the other hand, every abstraction developed into code introduces dependencies. Abstractions also often arise over time and must be tuned to a specific usage context. When your micro-frontend codebase is limited to a few functions, it's less likely that developers will attempt to create such abstractions. Instead, when they find an opportunity to reuse code, they just copy and paste relevant pieces, which is usually much better than introducing dependencies.

Service Boundary Enforcement

The architecture of a system is often influenced by certain analysis and design decisions. However, deciding on something and following those decisions are often not the same. Drift begins after services are split and responsibilities are agreed and documented. The lack of clear boundaries or the ability to cross them can lead to and allow developers to break previously agreed designs. There are tools such as code reviews or dependency inspections implemented in CI/CD pipelines, but with separate micro frontends it is not possible to deviate from the agreed architecture.

6 Common Requirements for Micro Frontends

In order not to lose any potential benefits of micro frontends, practical implementations of such architectures must satisfy some common requirements. The following six points are important and cannot be ignored:

independent deployment

- The biggest risk of using micro frontends is that they will require deployment coordination when they are not implemented correctly. In addition to a good design that encapsulates meaningful functionality in a single component and always ensures backwards compatibility, the components themselves must be deployable one by one without any coordination.

hot deployment

- The team developing some piece of the application must be able to deploy new versions without any downtime. Strategies such as rolling updates or canary deployments must be considered. Using an advanced HTTP routing mechanism with a well thought out path system can help a lot.

Unified styles/components

- Building applications as incompatible tiles can have a disruptive effect on user experience. The problem of how to ensure visual and behavioral consistency must be addressed from the very beginning of the introduction of micro frontends. The solution typically covers both technical (shared UX library) and organizational aspects (shared UX team).

Authentication and Authorization

- Obviously, the user has to authenticate only once. Authorization context and rules must be shared by all components of frontend and backend.

Communication across components

- Even though communication between components introduces coupling and thus should be avoided, it is difficult to imagine an application composed of completely separate parts. Specific micro frontends must be able to share the application context (i.e. user or other resource identity) and notify each other of internal state changes. The chosen communication method should prefer indirect event-based or address bar communication over direct use of other component APIs.

Search Engine Optimization

- The severity of this requirement depends on the specific use case, but for some applications it is a first class citizen to be addressed.

Micro frontend technology - 3 ways to decouple the frontend

Micro frontend technologies can be divided into three categories, each of which has some advantages and disadvantages. We can distinguish between:

Build-time integration - the application is generated as a bundle and then delivered to the user in one go
Server-side integration - integrate the application while serving the page, and the user's browser gets the complete application
Client-side integration – the application is delivered in batches to the user's web browser, which is then integrated into the browser

Below we take a closer look at each of these three approaches by using the example of a fitness tracking app like Strava or Endomondo. Each of these apps has similar features and functionality, such as a dashboard showing a summary of the athlete's profile, their latest activity, some ongoing challenges, etc.

build-time integration

The first way to decouple the frontend is to organize the code base in separate repositories. With build-time integration, each micro frontend is built and published as an independent package. Complete applications import these packages and compose the user interface from the included components.

This way, reasonable team independence can be achieved with a little effort in organizing teams and properly dividing functionality between teams. While it won't provide all the possible benefits of micro-frontends, such as technical diversity or deployment autonomy, it has the advantage that it doesn't require any additional tools beyond what developers already use.

Build-time integration simplifies consistency guarantees compared to other approaches. It's also the easiest and most efficient way to reduce the amount of data transferred to the user's browser, since the entire application package is optimized during the build phase.

Something to consider when designing the fitness tracking application in our example is to use indirect communication between components, which will reduce coupling.

server-side integration

The general idea of the second method is shown in the figure below.

The browser's request for the page (1) comes from the "Layout Service", which first requests the "Page Template Service" for the page layout (2). The layout contains HTML-compatible tags that contain the URLs of the page fragments to include (3). A "layout service" requests all content that contains parts that implement a specific function and calls the service. A more advanced implementation of the layout service executes queries in parallel (4), supporting failover and fast-response streaming.

After all the parts have been retrieved (5), the full content of the page is ready to be requested and returned to the browser (6).

The layout service plays a central role in establishing consistent behavior of the application from the user's perspective, but it consists of parts that are developed and deployed independently.

Server-side integration is useful when the application consists of pages composed of many independent tails, some user-specific and some shared between users, as e-commerce sites typically have.

There are many techniques for applying this pattern, such as server-side includes, edge-side includes, and Zalando's project Mosaic with the "fragment" tag.

The server side includes

Server-side include (SSI) is a scripting language interpreted by a web server to include the contents of one or more files into a web page. The language syntax is based on instructions placed in HTML comments, which are processed by an SSI-enabled Web server.

<!--#directive parameter=value parameter=value -->

The most commonly used directive is "include", which allows to include one document into another. Included documentation can be referenced by a path relative to the current file directory. For example:

<!--#include file="footer.html" -->

A more powerful and recommended option is to use virtual parameters, which can specify any resource, including CGI scripts or remote pages:

<!--# include virtual="/athlete/768769879/details" -->

The language also provides variables and conditional clauses to create more context-aware content on the page.

SSI is supported by popular web servers such as Apache or NGINX.

side includes

Edge Side Includes (ESI) is a markup language for edge-level dynamic web content assembly. The goal of ESI is to address the problems of Web infrastructure scaling and content distribution. Similar to SSI, it provides embedding via the esi:include tag:

<esi:include src="http://befit.com/footer.html" />

Conditional execution commands combined with a large number of predefined variables enables truly dynamic content on the pages served to users.

<esi:choose>
    <esi:when test="$(HTTP_COOKIE{group})=='Advanced'">
        <esi:include src="http://befit.com/advanced.html"/>
    </esi:when>
    <esi:when test="$(HTTP_COOKIE{group})=='Basic User'">
        <esi:include src="http://befit.com/basic.html"/>
    </esi:when>
    <esi:otherwise>
        <esi:include src="http://befit.com/new_user.html"/>
    </esi:otherwise>
</esi:choose>

Caching proxy servers such as Varnish or Squid support ESI.

Zalando's Mosaic Project

Built into Zalando, Mosaic is one of the first mature, purposeful micro-frontend frameworks for server-side integration.

The central point of the Mosaic architecture is "Tailor", the implementation of layout services in this server-side micro-frontend architecture. In order to include micro frontends in a page, the "fragment" tag is used:

<html>
<head>
    <script type="fragment" src="http://assets.befit.com"></script>
</head>
<body>
    <fragment src="http://athlete.befit.com"></fragment>
    <fragment src="http://trainng-log.befit.com" primary></fragment>
    <fragment src="http://challanges.befit.com" async></fragment>
</body>
</html>

Fragment tags provide additional useful properties compared to normal SSI or ESI tags:

primary – represents the fragment that sets the response code for the page
timeout – optional fragment timeout in milliseconds (default 3000)
async - defer the fragment to the end of the body tag
public – prevents Tailor from forwarding filtered request headers from upstream to fragments
fallback-src – the URL to fall back to the fragment in case the current fragment times out/error

As mentioned above, Mosaic is designed to serve micro frontends and provides the following functional benefits:

Write pre-rendered markup on the backend. This is important for SEO and speeds up the initial render.
Make sure to get to the first byte quickly. Tailor requests fragments in parallel and streams them as quickly as possible without blocking the rest of the page.
Execute performance budgeting. This is very challenging in other settings because there is no single point of control over performance.
Fault Tolerance: Render meaningful output even if page fragments fail or time out.

If more sophisticated template management is required, page templates can simply be served from the file system or from a dedicated service.

The second part of the mosaic is the captain. Along with Innkeeper, Skipper built an advanced HTTP router that can be used when the complex world of microservices needs to be hidden. Skipper itself provides rule-based routing of HTTP requests, with filtering and enrichment. Innkeeper serves as the API for runtime Skipper rule management.

Server-side integration allows for easy writing of applications from micro-frontends, but it does not solve the challenges that arise when truly rich front-end applications are required.

client integration

Last but not least is the client integration approach. Here, micro frontends are built to integrate the application into the user's web browser. Each part of the application is delivered independently to the browser, and then the application is glued when rendered.

Using this approach, building applications at runtime requires no additional infrastructure, and it seems to be the most flexible. Application components can share some user context, so as if integrated at build time, without affecting other requirements of the micro frontend.

frames

iframes are an old client-side integration technique that can be used to embed one HTML document within another. In the context of micro-frontends, the solution consists in embedding each micro-frontend application page layout using an iframe tag with the src attribute pointing to the URL serving the application.

Similar to SSI/ESI in this approach, each micro frontend can be hosted on a different address. In contrast to SSI/ESI, the client browser is responsible for downloading each fragment independently and displaying the full page.

<html>
   <body>
     <iframe src="http://athlete.befit.com" style="border: none;"/>
     <iframe src="http://trainng-log.befit.com" style="border: none;"/>
     <iframe src="http://challanges.befit.com" style="border: none;"/>
   </body>
</html>

To be a full-fledged micro frontend, an application embedded in an iframe should be able to communicate with its parent. This can be achieved by using the window.postMessage() method, but in most cases it is good practice to wrap such a low-level API with a library that simplifies integration from a micro-frontend perspective.

In addition to covering the standard use case of data exchange between micro frontends affecting the state of the rendered content, there is a need to enable communication between the parent and micro frontends. The latter ensures that the size of the iframe fits the size of the micro frontend content. When the iframe content overflows, information about the actual size of the embedded content must be propagated to the parent application, and the iframe height must be adjusted by the parent application.

It works best when the microfrontend platform itself requires iframe-based integration to ensure the highest level of isolation between the parent application and the microfrontend. In this case, micro frontends can be created using any technology or framework, including simple legacy application integrations that are unique in client integration.

Deployment of micro frontends also doesn't require any special way to build or package the source code.

The iframe method ensures that deploying a new version of a micro frontend does not affect other already deployed micro frontends. This technical freedom ensures that the entire system will not be stuck in a certain framework, because micro-frontend compatibility is not required. This allows technical debt to be paid according to each development team's actual business priorities.

This high degree of isolation simplifies integration, but at the same time it introduces some UX constraints that should be considered when considering your integration solution.

When your main concern is UX design, iframes are definitely not the best choice. Can provide good UX design (and in the case of responsive web design as well), but it's a little more complicated than the other methods. The main limitation is due to the fact that the micro frontend content cannot extend beyond the iframe boundaries. For example, popups displayed over multiple iframes were not displayed correctly.

Another factor to consider is the resource overhead of downloading to the browser. Each resource (css, js, etc.) required for a particular micro-frontend must be downloaded separately. While this is probably not a problem for most workstations used by clients these days, please note that it is not possible to load only one instance of the front-end framework core library into memory.

Single SPA

Single SPA is a JavaScript framework designed to build user interfaces consisting of multiple single-page applications, which promises the coexistence of many frameworks. Even different versions of the same framework can be mixed in one page.

When using a Single SPA, each micro frontend can be deployed independently. Another nice feature is lazy loading of code. Specific microfrontend bundles are only loaded when needed, which improves application loading speed.

The architecture of any Single SPA application consists of two concepts:

The application - the micro frontend itself. Every application can respond to URL routing events and must know how to bootstrap, mount and unmount itself from the DOM. The main difference between a traditional SPA and a Single SPA application is that the latter must be able to coexist with other applications and cannot each have its own HTML page.
Single SPA config – Registers the application's HTML pages and JavaScript with a single SPA.

Embedding a micro frontend into a Single SPA does not require extensive tweaking of the frontend. A new micro frontend declaration needs to implement a single SPA lifecycle function and expose a file with those implementations to the main application.

Single SPA lifecycle functions are very similar to React component lifecycle functions - the object props has a property domElementGetter that returns the DOM element on which the micro frontend should be placed or removed.

bootstrap - will be executed once before installing the micro frontend for the first time.
mount - will be executed when the activation feature condition is met (i.e. correct URL) or when the micro frontend is mounted manually.
unmount – will be executed when the activation feature conditions are not met (i.e. incorrect URL) or when the micro frontend is manually uninstalled.

How to mark a front-end application as a single SPA micro frontend in code
If you want to mark a front-end application as a Single SPA, the first step is to prepare a main micro frontend file and implement the lifecycle methods. This can be done manually, but the framework provides a handy helper to do it.

import React from 'react'
import ReactDOM from 'react-dom'
import singleSpaReact from 'single-spa-react'
import root from './root.component.js'

const reactLifecycles = singleSpaReact({
   React,
   ReactDOM,
   rootComponent: root
})

export function bootstrap(props) {
    return reactLifecycles.bootstrap(props);
}

export function mount(props) {
    return reactLifecycles.mount(props);
}

export function unmount(props) {
    return reactLifecycles.unmount(props);
}

In a second step, you can use Webpack to bundle your application into a single bundle file, say athlete.bundle.js, and expose it from any server accessible to the client.

How to use the Single SPA micro frontend in a frontend application

The application concept = Single SPA as a framework

The first step is to register a micro frontend in the root application. For this you should use the following function:

registerApplication(
    appName: string,
    applicationOrLoadingFn: () => <Function | Promise>,
    activityFn: (location) => boolean,
    customProps?: Object
);

appName – the name that will be used as an identifier in the mono spa
applicationOrLoadingFn – a function that can return an application or an application promise
activityFn – A function that returns true when the app must be installed and false when the app must be uninstalled.
customProps – An optional object that will be passed to the lifecycle methods whenever they are called.

The last step is to start() the single SPA engine, and you're all set.

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

const domElementGetter = () => document.getElementById('micro-font-end-container');
const pathPrefix = (prefix) => {
   return (location) => location.pathname.startsWith(`${prefix}`);
}

registerApplication('athletes', () => import ('athletes.bundle.js'), 
pathPrefix('/athletes'), {domElementGetter});
registerApplication('challenges', () => import ('challenges.bundle.js'), 
pathPrefix('/challenges'), {domElementGetter});
start();

<html>
<body>
   <script src="/dist/root.js"></script>
   <a onclick="singleSpaNavigate('/athletes')">Go to athletes</a>
   <a onclick="singleSpaNavigate('/challenges)">Go to challenges</a> 
   <div id="micro-font-end-container">
       //i.e. here micro frontends can be injected
   </div>
</body>
</html>

The parcel concept = Single SPA as a library

When using Single SPA as a framework, the container application is a simple container of applications that switch based on root changes. Another option is the package concept. Here, you create a container application in any framework as the basis of the system, and you have to install the package (or actually the micro frontend) directly in a specific location. Such a page can contain multiple micro frontends. This is closer to the concept of building a user interface as a composition of decoupled features, but at the same time visible and accessible.

Packages should also be unloaded at the correct time.

In the example below, React is used as the main framework, so componentDidMount and componentWillUnmount can be used to mount and unmount packages.

class AthletesMicrofrontendComponent extends React.Component {

    componentDidMount() {
        SystemJS.import('athletes.bundle.js')
            .then(athletesApp => {
               const domElement = document.getElementById('athelete-micro-frontend-id');
               mountParcel(athletesApp, {domElement})
            });
    }

    render(){
       return <div id="athelete-micro-frontend-id"></div>
    }
    ...
}

Comparison of micro-frontend solutions

The table below summarizes and highlights the main advantages and disadvantages of each approach:

technology	category	Example implementation	Advantage	vulnerable	suggestion
package at build time	build-time integration	NPN, yarn	Easy to set up - no additional tools required known to developers Code deduplication UX Consistency Made Easy	Lockstep release process - the entire package must be recompiled and deployed limited to one frame	Only use for small projects (no more than three teams) when the other options seem very complex
SSI/ESI	server-side integration	SSI – NGINX, Apache Http ESI - Varnish, Squid	Easy to setup - HTTP server and Cashes are part of every web application architecture Deployment is completely independent	Lack of cross-component communication - must be addressed in other ways Difficulty achieving a consistent user experience look and feel Lack of built-in authentication and authorization	For web applications such as e-commerce when the application and service architecture fluctuates less microservices
Professional micro-frontend middleware	server-side integration	Zalando’s Mosaic, Compoxure, micro-fe	Deployment is completely independent Excellent control over page performance and failover Built-in advanced dynamic routing with auto-discovery	Difficult to set up - requires additional components Lack of cross-component communication - must be addressed in other ways Difficulty achieving a consistent user experience look and feel Lack of built-in authentication and authorization	For e-commerce like web applications when the application and service architecture fluctuates widely with microservices
frames	client integration		Easy to set up - no additional tools required Deployment is completely independent High component isolation Communication across components Truly Framework Agnostic	Difficult to achieve deep linking Difficult to implement RWD high resource consumption	Use when framework agnostic and component isolation are key concerns and UX is not that important
Micro Frontend Framework	client integration	Single SPA	Full integration between micro frontends and container applications Supports all major JS frameworks lazy loading	not well documented engine	Used in rich applications composed of many communication micro-frontends

summarize

The Micro Frontends pattern really seems to be the missing piece of the puzzle if you want to get the most out of your microservices architecture. Depending on your needs, the exact solution may vary. For example, for an e-commerce site, you can choose any type of server-side integration. However, when your goal is a high-level coverage application, one of the client-side technologies will be your better solution.

If you think micro frontends are still too much trouble, at least choose build-time modularity. It always pays off in the long run.

If you have any experience with micro-frontends and their implementation, please share them below. We'd love to receive your thoughts and concerns and discuss the topic further.

This article: https://architect.pub/micro-frontends-missing-piece-puzzle-feature-teams
Discussion: Knowledge Planet [Chief Architect Circle] or add WeChat trumpet [ca_cto] or add QQ group [792862318]
No public	【jiagoushipro】【Super Architect】 Brilliant graphic and detailed explanation of architecture methodology, architecture practice, technical principles, and technical trends.
WeChat trumpet	[ca_cea] 50,000-person community, discussing: enterprise architecture, cloud computing, big data, data science, Internet of Things, artificial intelligence, security, full-stack development, DevOps, digitalization.
QQ group	[285069459] In-depth exchange of enterprise architecture, business architecture, application architecture, data architecture, technical architecture, integration architecture, security architecture. And various emerging technologies such as big data, cloud computing, Internet of Things, artificial intelligence, etc.
video number	[Super Architect] Quickly understand the basic concepts, models, methods, and experiences related to architecture in 1 minute. 1 minute a day, the structure is familiar.
knowledge planet	[Chief Architect Circle] Ask big names, get in touch with them, or get private information sharing.
Himalayas	[Super Architect] Learn about the latest black technology information and architecture experience on the road or in the car.	[Intelligent moments, Mr. Architecture will talk to you about black technology]
knowledge planet	Meet more friends, workplace and technical chat.	Knowledge Planet【Workplace and Technology】
LinkedIn	Harry	https://www.linkedin.com/in/architect-harry/
LinkedIn group	LinkedIn Architecture Group	https://www.linkedin.com/groups/14209750/
Weibo‍‍	【Super Architect】	smart moment‍
Bilibili	【Super Architect】
Tik Tok	【cea_cio】Super Architect
quick worker	【cea_cio_cto】Super Architect
little red book	[cea_csa_cto] Super Architect
website	CIO (Chief Information Officer)	https://cio.ceo
website	CIOs, CTOs and CDOs	https://cioctocdo.com
website	Architect practical sharing	https://architect.pub
website	Programmer cloud development sharing	https://pgmr.cloud
website	Chief Architect Community	https://jiagoushi.pro
website	Application development and development platform	https://apaas.dev

Thank you for your attention, forwarding, likes and watching.

[Micro front-end architecture] Micro front-end - the missing piece of the puzzle in the functional team