Best Practices and Recommendations

Architecture

Frontend

The frontend is a web component. You are free in your choice of framework, libraries and tooling, as long as you comply with the 6M Specification. However, please keep the following aspects in mind:

• Browser support: The component must support all current browsers with a share above two percent in our relevant target audience.
• Module/Nomodule: You may build different versions of a component, one to be loaded as type="module", the other as type="script" with the nomodule property attached. However, currently you can only reference one file as the entry point, so you would have to do feature detection there an inject the correct script tag based on the browser. (Some frameworks such as Stencil do this for you.) Later versions of the 6M Specification will allow to reference modules and scripts separately.
• Polyfills: Do not include polyfills in your code. You can expect polyfills to be loaded by the host page. Host pages are encouraged to use “smart” polyfill services which load polyfills based on browser/feature detection, such as polyfill.io.

Frameworks

The choice of framework is always an integral decision in the development of a software product. If you develop a new component, please make sure to pick the right framework. Especially, do not base that decision on your current skillset, but take the following aspects into consideration:

• Fitness for the job: As our microfrontends are web components, the framework should bring native support for reacting on attribute changes, it should
• Performance
• Overhead
• Maintainability

There are frameworks which

Middle Layer

The middle layer is a stateless service, which belongs (only) to your microfrontend stack. It connects the frontend with APIs and other services. This concept is also know as “backend for frontend” in other microfrontend environments. A middle layer usually does one or more of the following things:

• Authorization: Most internal APIs require some sort of authorization. In order to avoid putting credentials into the frontend, you will keep them in the middle layer; allowing you to control who is accessing APIs in your name.
• Aggregation: Sometimes the business logic of a microfrontend needs to collect data from multiple APIs and merge it into a custom data package for its frontend.
• Transformation: API results can be very “heavy” and also reveal information which should not be exposed in the context of the given business case. In this case, the middle layer will transform the API response into
• Caching: The middle layer can act as a kind of an “edge” cache to keep frequently needed and rarely changing data near to the frontend. Note that in many cases it makes sense to extract the caching logic from the middle layer into a dedicated caching service within your microfrontend stack.

Note: As the frontend and its middle layer are tightly coupled, the API between the two does not have to be versioned and is allowed break at any time.

Service Dependencies

6M components must not share, it is important that they don’t share private dependencies with other 6M components. The big benefit of 6M is the fast and independent delivery of features. You can not deploy a service as a part of one component and then have another component depend on it.

What you can do is: Operate the dependency as a “public” service. (Public in regard to the API, not necessarily from the network perspective.) It is important that this service is a product of its own, with a stable, versioned API and an independent lifecycle. Such a service would not know about the business logic of its downstream consumers.

This may sound a bit complicated, but it will ensure that you can release 6M components independently.

Project Setup

Repository Layout

The frontend and the middle layer can be maintained within one repository (mono-repo, i.e. two applications in one Git repository) or two different repositories (multi-repo, one repo per project). If you follow the multi-repo approach, you should have one additional repository for integration/deployment.

CI/CD

If you have frontend, middle layer, and possible additional services of your microfrontend stack in separate repositories, it is a good idea to set up the CI/CD pipeline in a way that all parts of the stack build their artifacts and push them to Artifactory, and then a dedicated repository will make atomic deployments of the entire stack. Have a look at the 6M demo component to see such a setup.

Connecting the frontend with the middle layer

• Do not require the integration to pass the middle layer URL via attribute.
• Do not inject the URL into the build artifact.
• Instead inject the URL during deployment.

README.md file

A README.md file must be present in the root of the repository. The file is not intended for users of the component; that’s what the 6m.json documentation is for. The README.md file adresses developers and must contain an overview of the technology (e.g. frameworks, architecture, design patterns) used for the frontend as well as the middle layer. Additionaly, depending on the nature of the component, it may contain information such as:

• Hints on serving frontend assets and/or running the middle layer in development mode without requiring a build,
• Requirements and recommendations on running the middle layer in production (e.g. environment variables, memory requirements),
• A roadmap for the component,
• Contribution guidelines,
• Branching/release strategy.