We are currently building multiple applications, including some mobile-enabled ones, and are restructuring our project into a Hydra-like architecture with multiple interconnected applications centered around a core main application. Initially, we chose Angular and Ionic for this purpose. The core application will serve as the foundation, with other applications integrated into it. We are seeking guidance on the best approach to structure, integrate, and manage these apps effectively, ensuring smooth operation across both mobile and web versions.
What do you think about this approach to combine multiple Angular 18 standalone applications into one?
Is it the best way to manage and scale them, or is there a better option?
Would micro services improve scalability, maintainability, and flexibility in this setup?
I also tried this approach.
If multiple developers are working on this project, could each one independently develop and manage an application as a micro service?
TL;DR - probably not, unless you are really really sure it won't bite you later.
Whilst it will make some things simpler in the short term, it will also introduce constraints that may impact you later. Managing a bunch of smaller things (in this case, separate projects) will introduce some complexity and therefore code/project management overhead, but will provide you with more flexibility.
In architecture the phrase "it depends" come sup a lot, because it's all about making trade-off decisions - each architectural decision you make has implications. There are always potential downsides, so often it's about deciding which set of downsides (and advantages) you want to tie yourself to.
In your specific case you should at least consider these aspects:
Reasons for change
Architecture is concerned with how a system is structured, and what the roles & responsibilities of each component are. Some components have a technical focus (e.g. logging sub-system, database technology specific data provider, etc), others have a functional focus (e.g. managing a product catalogue, managing customer contact details, providing a shopping cart, and so on).
Think about why a given application / component would need to change. Technical components will need to change if one of their dependencies changes - e.g. you change database technologies, or upgrade a framework version, etc; similarly if the business requirements change you'll need to make functional changes. All of these types of changes might introduce a breaking change and you'll want to restrict the "blast radius" of that change so as to reduce your rework/testing, etc.
If you are not familiar with it, SOLID and other OO related design principles address these sorts of concern at length. Reading up on these may not give you a quick answer, but they will give you a "deeper" answer that will serve you for the rest of your career.
We’re seeking guidance on the best approach to integrate these apps, managing both mobile and web versions effectively.
Development-time impacts (including testing)
What do you think about this approach ... combining multiple Angular 18 standalone applications into one?
I'd be cautious about combining them. Whilst it will make some things simpler, it will also introduce constraints that may impact you later. Managing a bunch of smaller things (in this case, separate projects) will introduce some complexity and therefore code/project management overhead, but will provide you with more flexibility.
This is why I started above by discussing change - because some changes will be much harder to handle if the project are combined. You question is possibly a lot broader than you realize. Regarding combining projects, get your team together and have a discussion around a whiteboard, discussing all the types of change you might have to deal with, and map out the pros & cons for each approach you might take.
Generally it's easier to combine separate small things into a single bigger thing, than it is to split a big thing into separate smaller things (which is one reason behind the evolution from Monoliths to Microservices). In your case, "combining things" might = API's, interfaces & contracts which work at runtime, as opposed to code-level combination like build references etc that apply at development time.
If multiple developers are working on this project, could each one independently develop and manage an application as a microservice?
If you are using source-control with check-in/out then yes, but that doesn't mean it would always be efficient or easy. Normally you'd want them separated out for isolated but stable development. That will make the coding easier and the challenge will instead be coordinating effort and releases.
Deployment & Runtime related impacts
What do you think about this approach ... combining multiple Angular 18 standalone applications into one?
I'm not an expert on Angular, but how do you package and deploy something? If you combine them, can you still build, package and deploy them separately? I'm assuming you would want to.
Actually I can't think of any specific runtime aspects that affect you right now, but in the end code has to execute, so it is definitely something you should not ignore.
Architectural Styles
An Architectural Style is a type of pattern that makes some structural decisions for you - this also includes setting out roles & responsibilities for each component, and various constraints as well; what they don't specify is implementation specific detail; architectural styles try to address broader sets of architectural questions and remain somewhat abstract, using principles as a basis - as opposed to a Software Design Pattern which are concrete and specific. Clean, Monolith, Microservices, and Headless are all examples of architectural styles.
In your case, if you have one or more backend services, you may want to keep those separate from your frontend, in which case you could adopt "Headless" as a style. You could then adopt further styles (e.g. Clean) for the backend. I'm not saying you should use Clean for this specific project, I'm just using it as an example.