Micro Frontends in Action is your guide to simplifying unwieldy frontends by composing them from small, well-defined units. Micro frontends deliver the same flexibility and maintainability to browser-based applications that microservices provide for backend systems.
You design your project as a set of standalone components that include their own interfaces, logic, and storage. Then you develop these mini-applications independently and compose them in the browser. There are many ways to achieve a Micro Frontend architecture. This list presents the essential and required material to come up with your very own Micro Frontend approach. In this approach, the web application is broken down into its features, and each feature is owned, frontend to backend, by a different team.
This ensures that every feature is developed, tested and deployed independently from other features. Multiple techniques exist to recombine the features — sometimes as pages, sometimes as components — into a cohesive user experience. Blog posts and web sites that are talking about the general concepts for a Micro Frontend architecture. Contributions welcome! Read the contribution guidelines first. When naming your element the only requirement the spec defines is that the name must include a dash - to maintain compatibility with upcoming new HTML tags.
The team namespace guards against collisions and this way the ownership of a feature becomes obvious, simply by looking at the DOM. When the user selects another tractor in the variant selector , the buy button has to be updated accordingly.
To achieve this Team Product can simply remove the existing element from the DOM and insert a new one. The disconnectedCallback of the old element gets invoked synchronously to provide the element with the chance to clean up things like event listeners.
Another more performant option is to just update the sku attribute on the existing element. If Team Product used a templating engine that features DOM diffing, like React, this would be done by the algorithm automatically.
To support this the Custom Element can implement the attributeChangedCallback and specify a list of observedAttributes for which this callback should be triggered.
To avoid duplication a render method is introduced which is called from connectedCallback and attributeChangedCallback. When deciding to go with a more sophisticated templating engine or framework inside the Custom Element, this is the place where its initialisation code would go.
But with document-register-element a lightweight and battle-tested polyfill is available to make this work in all browsers. But when you get into the details, there are still a few implementation problems in some frameworks. At Custom Elements Everywhere Rob Dodson has put together a compatibility test suite that highlights unresolved issues. Using Custom Elements is a great way to achieve a high amount of decoupling between the fragments of the individual teams.
This way, each team is free to pick the frontend framework of their choice. Try to avoid Micro Frontends Anarchy and create a reasonable level of alignment between the various teams.
This way, teams can share learning and best practices with each other. It will also make your life easier when you want to establish a central pattern library. But passing down attributes is not sufficient for all interactions. In our example the mini basket should refresh when the user performs a click on the buy button.
Both fragments are owned by Team Checkout blue , so they could build some kind of internal JavaScript API that lets the mini basket know when the button was pressed.
But this would require the component instances to know each other and would also be an isolation violation. A cleaner way is to use a PubSub mechanism, where a component can publish a message and other components can subscribe to specific topics.
Luckily browsers have this feature built-in. This is exactly how browser events like click , select or mouseover work. In addition to native events there is also the possibility to create higher level events with new CustomEvent Most native events also feature bubbling. This makes it possible to listen for all events on a specific sub-tree of the DOM. If you want to listen to all events on the page, attach the event listener to the window element.
Here is how the creation of the blue:basket:changed -event looks in the example:. The mini basket can now subscribe to this event on window and get notified when it should refresh its data. With this approach the mini basket fragment adds a listener to a DOM element which is outside its scope window.
This should be ok for many applications, but if you are uncomfortable with this you could also implement an approach where the page itself Team Product listens to the event and notifies the mini basket by calling refresh on the DOM element.
Imperatively calling DOM methods is quite uncommon, but can be found in video element api for example. If possible the use of the declarative approach attribute change should be preferred.
Securing the messages, queues, and API endpoints requires new approaches to security both in the infrastructure and the code. Microservices Security in Action teaches you how to address microservices-specific security challenges throughout the system.
This practical guide includes plentiful hands-on exercises using industry-leading open-source tools and examples using Java and Spring Boot. Integrating independent services into a single system presents special security challenges in a microservices deployment. With proper planning, however, you can build in security from the start.
0コメント