Introduction
Over the past year or so, and following the successes of our micro services architecture, Hackney embarked on a journey to align our web application strategy with that of our API platform. This meant breaking down our applications into domain specific components that could be combined and reused in different ways.
Out of this, and the timely addition of Amido to our agency collaborators, came the decision to adopt a micro frontend strategy for our frontend development.
A Bit About Micro frontends
So what are micro frontends? At its core, the micro frontend model basically adopts the same underpinning as that of microservices where the application is broken down into a series of reusable features and domain specific components in order to have a consistent user experience across the board. Each feature or component becomes an application in its own right and developed independently but brought together in composition of the complete application.
For domain specific features, these can be built by product teams responsible for that domain which means the domain specific skills and knowledge can be leveraged for these domain specific products. These products can take advantage of benefits of micro frontends such as:
- Technology agnostic – Each micro frontend isn’t dependent on the technology stack of another and teams can use tooling best based on their particular skills set.
- Faster development and deployment – Because a lot of the micro frontend strategy is around reusability. Any project reusing a shared component benefits from not having to invest the time in building their features independently.
- Isolated code – Each micro frontend is its own self-contained application and does not depend on the presence of another, which means the decoupled architectural state is maintained.
- Team prefixes – Naming conventions can be established to easily identify which team or domain a product belongs to.
- Site resilience – Due to the decoupled architectural state, if one micro-frontend goes down, it doesn’t mean the entire website becomes unavailable.
There are a number of tools and frameworks available for building micro frontends. For our flavour of micro frontends we decided on the Single SPA framework which brings together multiple JavaScript micro frontends into one application.
The diagram below gives an idea of what we were looking to accomplish, utilising reusable components wherever possible to maintain consistency and reduce developer effort.
The learning curve for adopting the Single SPA framework was not the easiest in my opinion but ultimately the benefits have been worth the investment in the time required to learn.
Our Journey to Adoption
As there were several work streams in our Modern Tools for Housing (MTFH) programme of work, we decided on a phased adoption. Since the Manage My Home stream was the team to propose the Micro Frontend approach and they had the required set of capabilities to successfully deliver a proof of concept, the decision was made for them to pilot the approach.
What emerged out of this successful pilot was a set of useful tools and reusable components. We now had several micro frontend applications that could easily be integrated into other projects, including a standard authorisation component, a standard header, and much more.
There was a slow initial uptake of the micro frontend approach for a number of reasons pointed out by several teams such as the learning curve required for adoption and that some projects had progressed so far that it would not have been cost effective at the time to reverse progress and adopt another approach.
What we eventually decided was that we would target any new projects and get them on board the micro frontend train to ensure we follow our defined approaches. The idea was that at the start of a project would mean less of a buy-in challenge. We had some new projects coming online that needed to make a decision on their frontend approach. We approached two of these, Single View and Temporary Accommodation and they decided to come on board.
Because these two projects were outside of the Modern Tools for Housing programme of work, there were a couple of unforeseen challenges arising out of the tooling being specifically designed for the programme, a simple example being the application title being fixed for the programme.
At this point we were still sorely lacking in our internal frontend capabilities and relied heavily on the skills of our agency partners. The two projects that came on board had their own specific take on how to extend and reuse the project outside of the programme. This ultimately meant that we had two new flavours of implementation which ultimately was not the strategy we were aiming for.
However, collaborating with these two projects facilitated a lot of learning and we slowly started to build our internal capabilities and identify ways of extending the tooling in a more consistent way.
Where we are now
Since our efforts to extend the micro frontend tooling beyond the scope of the Modern Tools for Housing project and the challenges we were able to overcome, we now have several projects using this tooling:
- Single View
- Temporary Accommodation
- Finance
- Manage Arrears (Leasehold services)
The diagram below shows a partial view of how our micro frontend components are being reused across these various projects, either directly reusing the shared service components or reusing our templates to build new ones.
We do still encounter challenges as we extend this tooling as it is now pretty much a learn as we go process. However, we are already seeing the exciting benefits of this approach such as not having to spin up an authentication process for each project as well as having a very consistent look and feel of our web applications.
So What’s Next?
There is still a lot of work to be done to incorporate all of the UI work happening across our projects. As we have new projects coming onboard and wanting to take advantage of reusable components, we want to make it easier for them to do so.
The diagram below sets out ideas on what the development timeline would look like for our continued micro frontend journey.
We have been working on a couple of useful templates such as root and feature component templates.
We want to make the deployment of these projects as seamless as possible while remaining in line with our standard deployment process. The work on the deployment pipeline continues to evolve and we will soon be at the point where a developer can start a project from the template and have a working deployment pipeline with minimal configuration.
We also want to be able to integrate and align any micro frontend projects that may have started before we were able to set up our project template. For better maintenance and support it would be ideal for these to share the same common components where applicable so work will be needed to get these incorporated.
With all of this in place it will be invaluable to have all of the processes, guidelines and governance around our micro frontends all consolidated into a playbook, a central location for information for any new developer eager to get cracking on a new frontend project.
There will always be opportunities to build and grow this ecosystem but we also need to remain vigilant and keep abreast of any emerging security vulnerabilities or incidents and get them resolved as quickly as possible. This is why we will continue working with our security assurance team to address any detected issues as quickly as possible.
Conclusion
From the initial introduction of the micro frontend approach until now, I’ve been excited and interested in the prospects and possibilities that it allows. It has shown me how far frontend development has come, from the early days of plain HTML, CSS and JavaScript, to these amazing frameworks that make application development such a rich and rewarding experience.
Where I was once filled with awe and overwhelmed with the amount of learning that would be required to build a frontend application, I am not part of a team that can deliver ui components in a way that was previously unimaginable.
I am really excited about this project and the possibilities it can open up as we build out our micro frontend ecosystem.
