Ask HN: Is this a thing? Config-driven monolithic front ends?
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?