Micro Frontends - Part 1: What and Why

“An architectural style where autonomously deliverable frontend applications are created into a more prominent entirety”

Micro Frontends are extensions of microservices architecture and aim to apply the same principle to the frontends.

           

In the early days of software development, both the frontend and backend components would be bundled into one application which we now call it as a monolith style of application. Physically this type of application can live in one code repository. And that code repository would contain directories for frontend and backend part of the application but it was a one large solution which contained UI and business logic which would be maintained by one large team.as the Monolith are huge, changing anything would be taken seriously as testing and deployment was a huge task as the impact of breaking anything else that was unrelated to the change.

Frontend and Backend: The industry soon realised the advantage of breaking the frontend and backend and at the same time we ended with separate teams that specializes in backend development and front end development. Things generally improved with the split but the backend teams started to suffer with scaling issues as the business logic , functionality and data grew so did the size of the BE. so when we started to realize that one backend system in the form of API and services had to serve multiple different types of frontend in the form of mobile application and web applications something had to be done to address these issues. 

So the solution of the backend system was to use microservices architecture to split the large monolith applications into smaller services and api’s each with the clear scope and responsibilities. And each microservice had a dedicated team that specializes within that services responsibility in terms of domain knowledge. And the frontend team would call different api’s for the different part of the frontend application and this would have been done via API gateway or a backend for frontend(BFF) API which would talk to other downstream microservices

So in last few years we realized that microservices at the backend resolved these scaling issue and now we have issues at the frontend side of the application

                       

Microservices design principles (same can be incorporable for frontend)

1. High Cohesion - each microservice has on responsibility and focus . I does one thing and does well
2. Autonomous - Each MS can be independently changed and deployed
3. Business domain centric - MS has one single focus but also represents specific business domain or function within the organisation
4. Resiliency - even when there is failure, the system is resilient failure. It tries to fail fast and embrace the failure by defaulting or degrading the functionality
5. Observable - Using centralized logging and monitoring see what each component is doing.. Also monitor the health
6. Automation - automate using the tools for independant testing and deploying

Problems with Monolith Frontends:

1. Scaling issues - with the architecture and the teams, the codebase has gone so large and intertwined so making small changes takes longer. Instead of scaling one part of the application you end up scaling the entire monolith. Also needs large team to maintain the application which means a small change needs a lot of coordination
2. Communication issues between large frontend team and backend teams for simple ui change as  the priorities of the teams will be different

3. Code and testing complexity can increase the risk of managing the monolith applications
4. Slow continuous delivery

           

Advantage of Monolith frontends:

1.     Single code base

2.     Easier to setup for testing and development purposes

As the monolith frontend codebase grows over time:

What Increases:

1.     Dependencies - FE dependencies on internal and external 3rd party libraries/components grows which also increases the overall complexity

2.     Team size:  to maintain the growing and complex code base the team size increase

3.     Coordination: as the size of the team increases, the coordination required to make a small change increases

What Decreases:

1.     Ability to Change : ability for adapting a change slows due to the coordination effort required, also the technology used in frontend becomes older and more stale as the project ages.

2.     Staff availability: As the tech stack and tech choices become stale, the availability of staff with a specific skill in the market also decreases.

3.     Innovation and releases

The above problems can be described with a graph of “Law of Diminishing Returns”

 

Micro Frontend to the rescue

The approach is quite similar to BE, we take our large application and split it into a smaller components, however there is a lot more for Micro Frontends approach than just splitting. We try to make our software vertically sliced end to end, which means our micro frontends are inline with supporting backend micro services. Each vertical slice is basically a end 2 end feature.

For example: 

Within your web app, you have a cart section which is an end to end feature in the form of a micro frontend which is a cart section and in the backend it has a microservice or number of micro services which support that micro frontend and this entire feature is owned by one team which supports, maintains and develops this feature end to end which includes micro frontend also the supporting microservices in the background and any storage associated with each one of those services. 

This type of vertical slicing and team ownership of end to end feature means we inherit now the benefits of microservices and we can now independently change, deploy feature end to end without affecting the rest of our application. If we have specific performance issues we can focus on scaling out that aspect of our application. We also now have the clear end to end ownership of the features within our applications. Also the team has the domain knowledge as they own the complete feature.

One of the key aspect of the Microservice architecture is to give the illusion of one unified application and not to give away the fact that the application is actually made up of multiple micro frontends. The most common scenarios to achieve this is to use a base app which is basically a shell housing our micro frontends. So the base app or shell or browser they interact with each other giving the user an illusion of one functioning application that's consistent and coherent.

In the next article we would be talking about Micro Frontend Design Principles.

Firefox 5 Released, is it better?

Mozilla has released Firefox 5, Sticking to its promise of a quick-release cycle, just three months after Firefox 4 made its debut in March.

According to Mozilla foundation, the Firefox 5 includes more than 1,000 improvements and performance enhancements that make it easier to discover and use all of the innovative features in Firefox. 



So here it is what it has in store:

Firefox 5 allows mobile users to tweak their privacy settings directly from their mobile devices. The settings page is laid out in a way that a user can exactly see which options are on and which are off.

One of the major changes is the ability to enable the Do Not Track feature. This is a feature being used by several new versions of browsers today. It lets you tell a site that you want to opt-out of third-party tracking for behavioral advertising. In Firefox 4 this feature was buried deep in the options -- Options >> Advanced >> General and under Browsing you'd check the option: Tell web sites I do not want to be tracked. Now you just need to go into Firefox Options >> Privacy and under Tracking, check Tell web sites I do not want to be tracked.

Most enhancements and improvements claimed by Mozilla seem to be minor bug fixes according to reviewers. Some significant changes include enhanced support for HTML5 and new support for CSS (cascading style sheet) animations. Firefox 5's user interface is quite similar to Firefox 4.

Some other changes in Firefox 5 are said to include better spell checking in some languages; improved JavaScript, memory and networking performance. 

Firefox 5 offers better Linux desktop integration and improved background tab performance.

Also on-board Firefox 5: The ability to play CSS animations, and the capability to instantly tinker with Firefox add-ons, without slowing down the show or shutting off the browser. 

Mozilla also insures that it can respond quickly to complaints from users, and more easily transform the browser experience to meet consumer need.

CSS tables - Do you know this?

HTML table is a very easy way to display tabbed panes . Using css div based layout to achieve tabbed layout is bit complicated using float selector in CSS. This can be easily achieved by using CSS tables.

CSS tables solve all the problems encountered when using absolute positioning or floats to create multi-column layouts in modern browsers.

Applying display property values to web page elements that is table-related  causes the elements to mimic the characteristics of their HTML table equivalents. Here, I will demonstrate how this will have a huge impact on the way we use CSS for web page layouts.

Here is How we can achieve it:

Specifying the value table for the display property of an element allows you to display the element and its descendants as though they’re table elements. The benefit of using  CSS table-based layouts is the ability to easily define the boundaries of a cell so that we can add backgrounds and so on to it—without the semantic problems of marking up non-tabular content as a HTML table in the document.

Let’s understand this with simple example: the three-cell grid layout shown below. We’ll look at three different HTML markup samples that will result in the same visual layout. 

<div class="holder">
<div class="table_row">
<div class="table_cell">CELL 1</div>
<div class="table_cell">CELL 2</div>
<div class="table_cell">CELL 3</div>
</div>
</div>


A set of nested div elements may not seem so very exciting, but hang in there, we’re building to something. The CSS is also very simple:

.holder {
  display: table;
}

.table_row {
  display: table-row;
}

.table_cell {
  display: table-cell;
  width: 100px;
  height: 100px;
  border: 1px solid blue;
  padding: 1em;
}

How Does This Work?

The display property allows you to specify a range of table-related values in order to make elements display as though they were table elements. The available display values are:

• table makes the element behave like a table element
• table-row makes the element behave like a table row (tr) element
• table-cell makes the element behave like a table cell (td) element
• table-row-group makes the element behave like a table body row group (tbody) element
• table-header-group makes the element behave like a table header row group (thead) element
• table-footer-group makes the element behave like a table footer row group (tfoot) element
• table-caption makes the element behave like a table caption element
• table-column makes the element behave like a table column (col) element
• table-column-group makes the element behave like a table column group (colgroup) element

This article has presented a basic primer to the usage of the table-related values of the CSS display property—finally, a source of relief for all those struggling to construct reliable grid-based layouts using CSS!