I am currently exploring how to scale a DotVVM application into a large; modular architecture think multiple teams working on isolated features/modules like dashboards, reports, user management, etc.
While DotVVMās MVVM model works great for small-to-medium apps; Iām unsure about best practices for organizing a codebase when it starts to grow significantly in size and complexity.
Iām grappling with include: Should each module be its own DotVVM project with shared base components? Is there support or a recommended pattern for lazy-loading modules / separating routes by domain to improve maintainability and performance?
Also, how should shared resources like master pages, styles, or ViewModel logic be handled across modules without tight coupling?
Iād love to hear how others have approached this kind of scenarioāor if the DotVVM team has any architectural blueprints or case studies to share.
Checked DotVVM | Component-based MVVM framework for ASP.NETSplunk course guide resources, and found it quite informative.
What pitfalls should I watch for if I try to scale beyond a monolith structure? Any thoughts or patterns would be hugely helpful.
I think @tomasherceg will have better idea, Iām more here for lowlevel engineering than enterprise-scale architecture. That said, here are my thoughts and few questions:
In general, DotVVM was designed primarily to make small-ish teams more productive, as that is how we and probably most of our customers operate. For instance, our primary goal is to bridge the frontend-backend gap ā it makes it easier to make a single āfullstackā change (think add a column from DB to frontend), but harder to separate the work for a team of frontend and another team of backend engineers. Itās harder to make a backend change without touching HTML, or a frontend change without touching C#.
As I understand it you want to separate your work along a different axis than frontend/backend, which means DotVVM should at least be compatible with your goals My question is what do you imagine to be modules. Separately deployed applications? Multiple repositories? Just multiple C# projects in one solution? Just āindepentā folders in one project? If you have some ideas how youād approach this with another tech stack, please share them, it will help in understanding what you are trying to accomplish.
ViewModels are usually tightly coupled with their pages, and how you structure the logic inside is up to you. Reusing non-trivial ViewModel across modules isnāt recommended, unless youāre also reusing the associated view (a markup control). You can share small-ish data models a base class (I think most our projects have an application-specific page view model base class)
Styles and JS are not very affected by DotVVM
For JS, DotVVM has the concept of view-module, which is again usually by design tightly coupled with its page.
Scripts/styles specific for one component are obviously distributed with that component
There are multiple kinds of components in DotVVM. Itās a bit more complex situation than most other frameworks due to the server+client nature, but all kinds of components can be distributed as a reusable package (as thatās kindof the point)
Master pages can also be shared even across applications with NuGet package, but I think itās easier to have a bit of duplicated code and then large common pieces of code distributed as components (e.g. menu as a markup control).
Overall, DotVVM is just a frontend framework, and we canāt stop you from doing anything you want to. If you want to lean heavily into developing custom components, feel free to ask more questions here on the forum; the documentation has gaps in some areas, but itās easy for me to help in this area. You might also consider getting a commercial support, I donāt think it will be a large expense if you have a dozen of teams of developers. It might make it easier to discuss details in private; the contract here is we answer for free making the Q&A public and searchable.
Modularity is not an issue with DotVVM - you can split the pages, viewmodels, components, and related content into separate projects.
I am not sure about the benefits of lazy loading, as DotVVM is mainly a server-side thing. Unlike Blazor Web Assembly, DotVVM does NOT need to download all pages and resources to the client.
What could be a problem is microservices - if āmodularityā means that each module would be a separate app, and you would need to host these āappsā in some kind of shell, I think it would be quite challenging to do without iframes (which bring a lot of other trouble). But I am not a big fan of micro-frontends, so I havenāt been even thinking about how to do it the best way.
But overall, you can achieve a good maintainability in DotVVM apps if you follow the best practices for viewmodels, especially the good structure of the viewmodels that reflects logical parts of the page.
My question is what do you imagine to be modules. Separately deployed applications? Multiple repositories? Just multiple C# projects in one solution? Just āindepentā folders in one project? If you have some ideas how youād approach this with another tech stack, please share them, it will help in understanding what you are trying to accomplish.