Microservice frontends apps - jellyfish-tom/TIL GitHub Wiki
[SOURCES]
- https://getwebstack.com/blog/micro-apps-vs-microservice-vs-micro-frontends/index.html
- https://micro-frontends.org/
- https://martinfowler.com/articles/micro-frontends.html
- https://www.trendmicro.com/en_nz/devops/21/h/micro-frontend-guide-technical-integrations.html
- https://blog.stackademic.com/the-problem-with-micro-frontends-32c6b9597ba7
- https://levelup.gitconnected.com/microservices-are-they-good-or-bad-the-truth-is-it-depends-d648811d5ac8
What is microservice
It is an application which is loosely coupled, highly testable, independently deployed, defining clear business domain boundary and maintain by a relatively small team
What are Micro Frontends?
The term Micro Frontends first came up in ThoughtWorks Technology Radar at the end of 2016. It extends the concepts of micro services to the frontend world. The current trend is to build a feature-rich and powerful browser application, aka single page app, which sits on top of a micro service architecture. Over time the frontend layer, often developed by a separate team, grows and gets more difficult to maintain. That’s what we call a Frontend Monolith.
The idea behind Micro Frontends is to think about a website or web app as a composition of features which are owned by independent teams. Each team has a distinct area of business or mission it cares about and specialises in. A team is cross functional and develops its features end-to-end, from database to user interface.
However, this idea is not new. It has a lot in common with the Self-contained Systems concept. In the past approaches like this went by the name of Frontend Integration for Verticalised Systems. But Micro Frontends is clearly a more friendly and less bulky term.
Core Ideas behind Micro Frontends
Be Technology Agnostic
Each team should be able to choose and upgrade their stack without having to coordinate with other teams. Custom Elements are a great way to hide implementation details while providing a neutral interface to others.
Isolate Team Code
Don’t share a runtime, even if all teams use the same framework. Build independent apps that are self contained. Don’t rely on shared state or global variables.
Establish Team Prefixes
Agree on naming conventions where isolation is not possible yet. Namespace CSS, Events, Local Storage and Cookies to avoid collisions and clarify ownership.
Favor Native Browser Features over Custom APIs
Use Browser Events for communication instead of building a global PubSub system. If you really have to build a cross-team API, try keeping it as simple as possible.
Build a Resilient Site
Your feature should be useful, even if JavaScript failed or hasn’t executed yet. Use Universal Rendering and Progressive Enhancement to improve perceived performance.
Comparison
Problems with Microfrontends/microservices
https://blog.stackademic.com/the-problem-with-micro-frontends-32c6b9597ba7
- High cost of infrastructure needed
- Oftentimes creation of separate DevOps team, which is contrary to what organizational structure should be when implementing microservices architecture (DevOps operator per team is better as it s more decentralized, agile and selforganized)
- In bigger organizations decision-makers tend to enforce strict regulations on tech stacks, deployment pipelines, and other processes, creating an antithetical environment where the spirit of microservices suffocates.
It’s crucial to recognize that implementing microservices isn’t just about breaking down a monolith application into smaller, manageable services. It’s about understanding the readiness of your organization, the flexibility of your infrastructure, and the willingness of your people to adapt.
Conways Law
Conway’s Law.
Named after computer programmer Melvin Conway, this law suggests that the structure of a software system will reflect the social structure of the organization that produced it. Now, if you take a moment to visualize the organizational structure of a typical large enterprise, you’re likely to picture an intricate web of interconnected departments and teams, governed by a top-down hierarchy.
So, when such an organization tries to implement microservices — an architectural style that thrives on decentralized, small, cross-functional teams — it’s like trying to fit a square peg into a round hole. The centralization and tightly-coupled interdependencies that typify large enterprises run contrary to the philosophy of microservices.
Communicating beetween Microfrontends
https://dev.to/luistak/cross-micro-frontends-communication-30m3
Best Solution (17.01.2024)
https://github.com/luistak/windowed-observable?tab=readme-ov-file
https://github.com/luistak/windowed-observable/blob/master/packages/react/README.md