[ericsilly]

Great question. WC doesn’t provide any architectural structure beyond code encapsulation for your UI widgets. But this alone gets you per-feature sandboxing, even more strictly if you use the shadowdom to get runtime isolation as well (I typically don’t, but it’s a good fit for many solutions). This allows you to move ahead pretty quickly, knowing you can tear out and replace these elements easily if you got it wrong or the needs change, without core changes to the app. Yes, you still need foundational services like data access & caching, personalization, etc, which sit outside of WC, but the “best way” for those things is typically very tied to what you’re trying to build. So for those, I typically just start with a functional “sketch” of each service with a lot of code separation, and let the architecture emerge through iterations of refactoring as I start to understand what I need. The biggest refactor problems tend to have to do with precedence of rules and order of code execution, with the biggest issues at initial load as arrival scenarios get more complicated. But no framework is going to solve those problems optimally for your app, and more likely, the frameworks create more obstacles to doing it well. And then there’s always the problem that your devs need to be really knowledgeable in the framework to not apply it badly.