Micro front-ends is the concept of breaking apart a front-end monolith. SPA's are usually built in one framework like Angular or React. Over time, this can get very convoluted and turn into a bad monolith (there are good ones).
The second part is that instead of building screens, you design features (like invoices or customers or catalog) and develop the set of views that encapsulate the targeted domain. This is all built in a separate project with a well-defined set of meta data. You deploy the feature-set into your integrated environment and the managing app is constantly on the lookout for new features-sets.
Then in some admin portion of your umbrella app, you provide access to API's to other feature-sets, and to users.
One of the key elements is to keep front-end dependencies separate. So the manager app might be Angular 9, the customer feature-set might be in Angular 10 with its own dependencies. Nothing is shared between the manager app and each feature-set and nothing is shared between feature-sets.
This provides a front-end that is malleable and reduces dependency creep.
This can also benefit from Domain-Driven Design, where you've segregated your domains and their API's, Events, and Data Storage.
So you should be able to "publish" a feature-set without any dependency on a central database, API mesh, or Event manager.
The key is to define your boundaries well and that is no small thing.
Based on this comment you do kind of sound like one. Could you elaborate on what you think 'Domain Driven Design' is, and what you think 'boundaries' are in the context of development? It would help dispel the impression I get that you're a clueless CTO who knows enough to be dangerous.
(apologies for being a bit rude perhaps; consider it a comment slightly in bad faith, but very curious to hear you prove me wrong)
DDD is a set of principles where you have conversations with your business partners, model scenarios, determine a ubiquitous language, and build software that mirrors those models and conversations. Determining your bound-contexts, their relationship to other bound-contexts, and determining where sub-domains belong. Though this can be confusing since you could have an "order" domain in several bound-contexts with different purposes. It also tends to move away from traditional OO modeling since we're pulling things apart, not abstracting them in order to decouple. I took Eric Evans 5-day class two years ago, but I've been professionally utilizing DDD for about five years including helping build Accenture's new performance management system.
I think the problem is your didn't concretely explain what your method entails and how it is any different from doing a plain HTML website or a Javascript one. Technically, there is a server, and a client, so what do you do exactly on the server and the client and how does it difference from other methods?
It's like someone asking you how does AJAX works and your start discussing functional programming. It doesn't explain what AJAX is and how does it differ from plain server side rendering.
Thanks for the in-good-faith response! I'd say that covers DDD pretty well.
I do still feel that the link between that and your suggestions in the initial comment are still tenuous and vague 'management-speak', but still, thanks for the response :). Obviously I don't know the exact details or how you're running things, so the best I can do is poke at it (in good faith).
You're not the only one. Sounds a lot like a former CTO of mine who couldn't write a line of code to save his life, but made sure to randomly toss out buzzwords and make sure you were aware of what he recently read in what I assume was an edition of Programming for Dummies.
My company talked about using micro front ends for a while. basically there was one microservice that actually served the web page itself and all of the controls and widgets on the web page were pulled from other microservices via API calls that each handled their own internal state.
