Creating Macro Benefits from Micro Frontends

Questions

What is a Micro Frontend?
- architecture & design pattern "An architectural style where independently deliverable frontend applications are composed into a greater whole" - Martin Fowler Missing presentation layer of micro services
- independent
- small in scope
- complete
- designed to work along each other
- kinda like power rangers
- mindset
  - often in the shadow of technical topics focused on intricate details of implementation
  - squads/teams/pods can focus on a value add for their customers/users e.g. team Search can focus entirely on "Finding the right product as fast as possible"
  - enables cross functional collaboration (diverse and inclusive teams can excel)
  - reduces friction between backend/frontend/design/product/ux/analytics/qa
Can we talk about Basecamp on how you are using that for project organization?

took a lot of inspiration on ShapeUp for our internal process which we name sherpUp
we run a series of projects for 6 weeks, each project can take 2-6 weeks each with at least 2 team members
each team is, depending on the topic cross-functional and at least a designer + developer
tackle often e2e, if a new feature requires a change in our data model/api/frontend the team will take care of everything
teams are independent and enabled

Yes
advocate for incremental development through frequent deployments (~ 10 deployments per week) and close collaboration with partners
feature flagging
remote configuration
keep our tech stack and tooling consistent across all frontends

Yes, it becomes easier if everything is in a mono repo
currently in the process of migrating the various frontends we have into a monorepo using the nx workspace
Adapting Atomic Design (think in atoms, molecules and organisms)
Organisms often remain as part of individual apps but adhere to the design system
shared CSS classes + variables + mixins help quite a lot

we provide a Javascript SDK that acts as an application shell and turns any website into a host
SDK or shell manages and maintains registered embedded elements (what we call micro frontends) that will be appended to the host DOM via iFrames
inter-application communication is created through a message bus via post messages
hosts are typically not in our control and our embedded elements need to be very flexible and adaptable to various environments e.g. devices/platforms and resolutions but also how much you can interact with each

we embrace embeddability through iFrames which provide a strict isolation especially in sandbox mode
important to limit functionality and content security policies
when using post messages to communicate between iFrames, checking for origin/destination and validating payloads is necessary
security teams might bring up concerns around click-jacking and end users not being able to distinguish or understand which part of the experience is part the host and which is ours ⇒ we visually indicate through "powered by sherpa°" and logo placements to provide clarity, nothing technical but very relevant