Micro-frontends using stencil.js: Scaling internal frontend products

Submitted Sep 5, 2018

Section: Full talk Technical level: Intermediate

Have you ever have to extend a legacy monolith? Have you ever wondered why you can’t make a new module in the technology of your choice? Have you ever envied backend devs for having this great architectural pattern called microservices? This talk will help you extend the microservices pattern to the frontend. Starting from the reasoning for why this pattern make sense for frontend to what are the frontend specific challenges in its implementation.

Outline

Problem Statement
Most companies nowadays have a single frontend admin app for all business concerns, since they dont want to educate their internal users(which are huge by the way) to use different apps. Aren’t we increasing code matainence and thus destroying developer productivity and happiness by not following the “Single responsibility” and “Separation of concerns” principles? Can we do this without affecting user experience and developer experience(Yes! that is a thing and a pretty important one).
All the possible solutions and the problems with them.
Enter micro frontends. What is it? How does it solves the problem?
What are the frontend specific problems that comes with it and their solutions:
Maintaining same design aesthetics across different apps
Synchronized deployments and health tracking
Performance issues when fetching multiple builds
Session management issues
How to implement this pattern using stencil.js?
A quick introduction to stencil.js
A quick refersher on native web components and shadow DOM
How to create a single application using all three component web frameworks: React, Angular and Vue? How do we practically acheive this? (The high level architecture)
Live Demo! (Showing live how different frameworks work together and how do we inspect them?)
Perks that this pattern comes with:
BYOS => Bring your own stack (Dev happiness).
Different teams responsible for different business concerns => “Separation of concerns”.
Your deployments doesnt break others’ code.
Could be a good technique to migrate your legacy code to a newer technology stack.
Separate repos => More security.
Key takeaways
Single responsibility and Separation of concerns => No need to maintain single frontend codebase for different buisiness concerns
Don’t break others code when deploying yours
Free yourself from some legacy global level settings which doesn’t hold true for your particular use case.
When migrating to a newer technology, no need to do it for the whole codebase in a single pass.
When making a new module, feel free to choose your own technology stack and make your own architectural choices and improve upon the older ones.

Speaker bio

Rajat is a software engineer and an avid open source contributor. He likes to test and play with the latest in technology and has a love for vanilla JavaScript as a language.

After working at various places ranging from a startup where you build products from scratch to a mid level organisation where you are supposed to extend the legacy projects, there is one important thing that he has learnt:
Compose small projects to build a big one, avoid monoliths.

He proposed the micro frontends architecture at his organisation and since then they have been migrating their frontend step by step.

Slides

https://docs.google.com/presentation/d/1L08aja9gefw3Gj8GqQXXyGAxRluB-bY6KsZFMEd8HVY/edit?usp=sharing

JSFoo: round the year submissions