Breaking Down The Last Monolith

In this talk, speaker Rahul Gaur describes his team's experiences, their learnings and the challenges they encountered while breaking down Innovaccer's front-end monolith and running it in production.

With a monolithic front-end, you don't get the pliability to scale across groups as assured by microservices. Besides not being able to scale, there is also the classical overhead of a separate backend and front-end team. Each time there is a breaking change in the API of one of the services, the front-end has to be updated. Especially when a feature is added to a service, the front-end has to be updated to ensure that customers can use the feature.

If you have a front-end small enough, it can be maintained by a team which is responsible for one or more services which are coupled to the front-end. This means that there is no overhead in cross team communication. But because the front-end and the backend cannot be worked on independently, you are not really doing microservices.

Rahul Gaur covers:
1. What are micro front-ends?
2. Why should micro front-ends matter to you?
3. Innovaccer’s case study of migrating a large angular 1.x application
4. Self-contained systems

https://youtu.be/VMGmgwYNmQY

Transcript

1. Breaking down the last monolith Presenter: Rahul Gaur UI/UX Platform Lead
2. Agenda • What are Microservices • What are Micro Frontends • Our Frontend Story • Common Integration Strategies • How We Deliver Value • Existing Solutions
3. What are Microservices ?
5. In a Backend Architect’s Mind... uS uS uS Frontend uS uS Gateway
6. Wait, What!? Our Microservices Have Actual Human Users?
7. Frontend and Services in Real World uS uS uS uS uS Gateway uS
8. What are Micro Frontends ?
9. Vertical Decomposition Frontend Platform Fe FE FE FE Backend Platform uS uS uS uS uS uS
10. Our Frontend Story
12. User interface Business logic Persistence We started building a monolith, which had numerous things inside of a single system… Various Domains
13. Breaking it Down
14. … and wrap every domain in a separate, replaceable web application … With all these layers in one place, our monolith kept growing... ...If you cut a monolithic system along its very domains …
16. Common Integration Strategies
17. The way to reduce product development time is by reducing the incremental cost of building new features!
18. Key Objectives Team Ownership Develop Independently Run Independently Technology Agnostic Fast Loading Native Support Sharing Basics Modular Corporate Identity Smooth User Interaction
19. • Team Ownership • Develop Independently • Run Independently • Technology Agnostic • Fast Loading • Native Support • Sharing Basics • Modular • Corporate Identity • Smooth User Interaction Standalone Nginx Based Routing Passed Failed 6 4
20. • Team Ownership • Develop Independently • Run Independently • Technology Agnostic • Fast Loading • Native Support • Sharing Basics • Modular • Corporate Identity • Smooth User Interaction Server Side Includes Passed Failed 7 3
21. • Team Ownership • Develop Independently • Run Independently • Technology Agnostic • Fast Loading ->Lazy load ? • Native Support • Sharing Basics • Modular • Corporate Identity • Smooth User Interaction Code Level Integration Passed Failed 7 3
22. • Team Ownership • Develop Independently • Run Independently • Technology Agnostic • Fast Loading • Native Support • Sharing Basics • Modular • Corporate Identity • Smooth User Interaction Application Shell Architecture Passed Challenges 7 3
23. Lazy Load and Routing
24. Loading Manifest
25. UI Engine
26. UI Engine • Simple, declarative dependency injection based application composition layer • Application lifecycle management • Application shell architecture and pluggable micro frontends • Support for both browser and server environments
27. UI Engine - App Shell
31. UI Engine - Micro Frontend
32. UI Engine - Single-Spa.js
33. UI Engine - Single-Spa.js
34. A plea for the monolith Monolith is not a bad design choice Microservices constrain you to do what is optional* while creating a monolith
35. UI Engine - Monolith
36. Styling Infrastructure - Containerization or ServerLess ? Challenges
37. How We Deliver Value
38. Metrics Legacy UI UI Engine First Paint 11.53s 3.60s Full Page Load 23.57s 7.46s Total Static Resources 2.8MB 220KB Landing Page
40. Process Using Design System and Pattern Library Develop a new feature or fix bug or any enhancement We encourage peer code review followed by final decision to merge taken by maintainer of module. staging and master branches have CI integration Every datashop package is published on private npm repository following a breaking.feature.fix convention. Docker Build process can access private npm registry and create docker images for dev, staging and production environments Production Docker builds are tagged with semver version number eg: datashop-engine:v2.8.16 datashop-engine:staging, incare-ui:develop, indata-ui:develop,
41. Independent Deployment
43. Incremental Upgrades
45. Onboarding and Innovation
47. Summary Why Choose A Monolith If You Don’t Have To ? If You’re fan of Single Page Apps at least build more than one Few organisations are in business of delivering APIs - UIs matter Frontend Monoliths are just as good, or bad, as backend monoliths
48. • Single-Spa.js • Open Components • My blog post on dev.to Deep Dive into Micro Frontends
49. Questions ?
50. Thank You Github: @aregee Twitter: @iamaregee Breaking Down the Last Monolith - Published here are under Creative Commons ShareAlike 2.0
51. Appendix
52. Metrics Legacy UI UI Engine First Paint 33.15s 2.65s Full Page Load 43.63s 10.14s Total Static Resources 2.8MB 1MB Data Explorer Page
54. Metrics Legacy UI UI Engine First Paint 16s 2.65s Full Page Load 29.76s 7.49s Total Size of XHR Response 354 KB 38.6 KB Total Static Resources 2.8 MB 1.1 MB ETL Flow Builder Page