Micro Frontends & Customer Experience - Part II

In the first post on Micro Frontends, I shared and went over the current Monolithic application architecture of our Flight Reservation System, along with the disadvantages associated with it.

Disjointed customer experiences do good to nobody — customers have to hop to and from different applications for various bits & pieces of information and user actions. And for the Product Engineering team(s) that has actually built the flows, there is not truly a good (central, collective) method to track and monitor the customer experience. Or even continue building a solid customer experience moving forward.

After a customer has reserved their flight, how would engineers know what percentage of them visited the Ticket SPA to view ticket details? Or the Payments SPA? Where would the responsibility lie in tracking those user metrics? Did any customers drop during any of the flows? How would we A/B test potentially new customer features?

Switching to a Micro Frontend-oriented Architecture

This type of application architecture enables a well-connected and guided customer experience. Flight Central (the base application) connects all the different business flows (reserve a flight, view ticket details, flight status, payment, etc.).

The customer will not have to jump from application to application, as Flight Central will be the entry point for displaying all of the different features for flight reservation.

Plus, you also get:

• Long-term Agility — Ability to scale and grow features with less dependencies (separate isolated API/microservice for each experience)
• Unified Analytics collection — Have the base application collect the metrics for entry points into flight reservation, ticket details, payments, etc.
• Code & contribution standards established — Since multiple product teams may likely be developing different parts of Flight Central (ex: Flight Reservation product team, Payments product team, etc.), you will need to implement cross-functional standards delineating curbs and boundaries, alignments and autonomy. Factors like code coverage, acceptable code, accessibility standards, performance. This will be hard to implement, will involve lots of growing pains discussion and back and forth, agreements/disagreements will happen. But worth it for the long haul.
• Easier to run A/B Tests — You can use Optimizely to A/B Test and experiment with different possible features to get realtime feedback from customers.
• Customer-friendly — Shared UX designs and components, familiarity, easier to navigate are all desirable experiences.
• Easy to host — Use Amazon S3 for static web hosting.

❗Disclaimer: Again, all of this will not be easy to implement in the beginning, especially in a rather large company. Buy-in will be very difficult from other engineering teams, middle and upper management, etc. But it’s worth it in the long run, if everybody wants a stable, scalable, enjoyable customer experience.

So, go about it in stages. I would recommend doing a quick preliminary proof of concept to show your peers the advantages and long-term gains. That will help make it harder and harder for anyone to say no.

In the next segment, I will go into some pitfalls to avoid, and other technical benefits of adapting to a Micro Frontend-oriented Architecture.

Please share your thoughts & feedback if you have any. Thank you for reading! 🙂