I'm trying to research different approaches to very complex frontends, but I can't seem to find the right search terms for one in particular. I'll do my best to describe it here in the hopes that someone can point me in the right direction, and as a bonus anyone who has experience with this type of architecture can share tips/warnings.
I'm designing a web application that sits on top of disparate workflows as a cohesion layer, making them feel more like a single product. Think aggregation functionality like notification center, search, dashboarding, help, etc.
The problem I'm trying to solve is how to build something flexible enough to support the different teams' workflows while protecting a consistent user experience. I'm hesitant to invest in a micro-frontend approach like single-spa or web components, but I don't think a monolithic approach has any hope of scaling (e.g. a single frontend team that has to understand and interact with dozens of different domains / services / workflows will become a painful bottleneck). One possible middle ground would be (for lack of a better term) a 'config-driven monilith': where a single team owns a few core experiences (landing page, dashboards, search, etc) and teams integrate by 'configuring' them through the use of control/data-plane APIs.
To give an example: for a dashboard, each team configures the expected data shape and e.g. importance (constrained by the control plane APIs), and then pushes data for users following that schema. The core team would own rendering the dashboard based on the config and pushed data. We could discuss the trade-offs of push/pull, but the point is each team isn't left to its own devices on UX, and the core team doesn't have to become experts in each domain. This is the simplest example I could think of, things obviously get more complex for data capture/forms.
Is there a name for this approach to building a complex frontend? Any examples out there?
What really helped was the PM team was very consistent as well. They knew how important consistency was and didn't argue if one team had already designed a save button, then they were cool with using the same button on the other sub team. Make sure you have full agreement with your PMs!
Lastly, unit test everything! The core team was frequently blocking the sub teams because they would make breaking changes. Now that our process and teams are a bit more mature it happens less, but working on the culture around this will help. Ensure that people see it as "helping out another team" rather than a "us vs them" situation. Having a CI system that runs tests on code before its checked into master is worth every second spent creating and maintaining it. And also checkin code asap, you'll have less integration issues. We also had QA that tested across the subTeam work.
I'm not sure what the name of this is, but it worked for us :)