title | date | tags | categories | ||||||
---|---|---|---|---|---|---|---|---|---|
Journey to Microfrontend: Pilot |
2021-06-09 19:43:03 -0700 |
|
|
- Want to try new tech? in small scope, yes!
- A single UI layer is hard to scale
- Single deployment becomes a bottleneck. your changes can be blocked by another team changes to be deployed.
- Single point of failure.
- Changes require many people to verify.
- Reliable E2E tests are hard.
- Shared tools? Webpack config outdated. Which team will do updating?
- Independently deploy? rebuild all the app or just a fragment?
Microfrontends are the technical representation of a bussiness subdomain, they provide strong boundaries with clear contracts, also they avoid sharing logic with other subdomains Luca Mezzalira, Chief Architect at DAZN
If we can't declare context-boundaries between domain, don't think about microfrontend.
Avoid to share components or code across different bounded contexts, abstraction could make our code more complex to maintain in the long run, the communication overhead could become a bottleneck for our organizations.
The main challenges with scaling frontend applications are scaling the teams, reducing the communication overhead and innovate!
We split monolith to micro. So we have to do the integration.
- Links between fragments.
- Build-time. How much updates should be build?
- Server-side
- Frontend:
- User experience
- lag?
- reload all the time?
- mismatching content/state
- Developer experience
- Are you willing to do the update a header for 5 times?
- Bounded-context stop you doing update in one place. sometime you must update through many repo => monorepo can help here.
- Small bundle sizes
- User experience
- Microservice stuffs:
- Deploy independently
- Hightly decentralized
- Dev/Prod parity
TBC
- Dockerize
- kubernetes
- Helm?
- Framework:
- Module Federation
- https://single-spa.js.org/
- https://luigi-project.io/
- https://qiankun.umijs.org/ -> production ready base on single-spa
- SSR micro frontend: