Service discovery
The frontend discovery pattern improves the development experience when developing, testing, and delivering micro-frontends. The pattern uses a shareable configuration that describes the entry point of micro-frontends. The shareable configuration also includes additional metadata that is used for safe deployments in each environment by using canary releases.
Modern frontend development entails using a wide variety of tools and libraries to support modularity during development. Traditionally, this process consisted of bundling code into individual files that could be hosted in a CDN with the goal of keeping network calls at a minimum during runtime, including initial load (when an app opens in a browser) and usage (when a customer performs actions such as choosing buttons or inserting information).
Splitting bundles
Micro-frontend architectures solve the performance issues caused by very large bundles generated by individually bundling a large set of functionalities. For example, a very large e-commerce website can be bundled into a 6 MB JavaScript file. Despite compression, the size of that file might negatively impact the user's experience when loading the app and downloading the file from an edge-optimized CDN.
If you split the app into home page, product details, and cart micro-frontends, you can use a bundling mechanism to produce three individual 2 MB bundles. This change might improve the performance for first load by 300 percent when users consume the home page. The product or cart micro-frontends bundles are loaded asynchronously only if and when the user visits the product page for an item and decides to purchase it.
Many frameworks and libraries are available based on this approach, and there are advantages for both customers and developers. To identify business boundaries that can result in decoupling dependencies in code, you can map different business functions to multiple teams. The distributed ownership introduces independence and agility.
When you split build packages, you can use a configuration to map micro-frontends and drive the orchestration for the initial load and for post-load navigation. Then, the configuration can be consumed during runtime rather than during build time. For example, the client-side frontend code or server-side backend code can make an initial network call to an API to dynamically fetch the list of micro-frontends. It also fetches the metadata that's required for composition and integration. You can configure failover strategies and caching for reliability and performance. Mapping the micro-frontends helps make individual deployments of micro-frontends to be discoverable by previously deployed micro-frontends that are orchestrated by a shell app.
Canary releases
A canary release is a well-established and popular pattern for deploying micro-services. Canary releases bucket the target users of a release into multiple groups, and release changes gradually as opposed to an immediate replacement (also known as a blue/green deployment). An example of a canary release strategy is to roll out a new change to 10 percent of the target users, and add 10 percent every minute, with a total duration of 10 minutes to reach 100 percent.
The goal of a canary release is to get early feedback about the changes, monitoring the system to reduce the impact of any issues. When automation is in place, business or system metrics can be monitored by an internal system that can stop the deployment or start a rollback.
For example, a change might introduce a bug that, in the first couple minutes of a release, results in a loss of revenue or a performance degradation. Automated monitoring can initiate an alarm. With the service discovery pattern, that alarm can stop the deployment and immediately roll back, affecting only 20 percent of users instead of 100 percent. The business benefits from the reduced scope of the issue.
For an example architecture that uses DynamoDB as storage to implement a REST Admin
API, see the Frontend Service Discovery on AWS solution
