Instead of providing one monolithic symfonia binary, we should look into splitting the project into multiple cargo workspaces, where each workspace is an individually deployable part of symfonia. This has several benefits:
1. More modularity
Splitting the project into smaller, individual codebases will ensure that each workspace functions independently, making it easier to reason about the codebase itself.
2. Scalability
If demand grows, a monolithic architecture is quite cumbersome to scale efficiently. I promise that microservices aren't just a cool tech buzzword, they can actually make our lives easier :P
3. Reusable components: From us to the outside world
The individual workspaces can be depended upon in other contexts and projects, like building blocks.
4. Reusable components: From the outside world to us
When structuring your application as microservices, one can more easily slot in and exchange parts as needed. I have been thinking of using Lust as a CDN server, while perhaps using something like rauthy for authentication. Taking advantage of projects tailor-made for these specific things will mean that those parts will likely be of higher quality than if we wrote them ourselves, while we can focus on our actual core product. We already have enough work on our hands. Why not use a thing that already exists?
In lieu of these upsides, I do not see any reason to not go ahead with working on these changes.
Instead of providing one monolithic symfonia binary, we should look into splitting the project into multiple cargo workspaces, where each workspace is an individually deployable part of symfonia. This has several benefits:
1. More modularity
Splitting the project into smaller, individual codebases will ensure that each workspace functions independently, making it easier to reason about the codebase itself.
2. Scalability
If demand grows, a monolithic architecture is quite cumbersome to scale efficiently. I promise that microservices aren't just a cool tech buzzword, they can actually make our lives easier :P
3. Reusable components: From us to the outside world
The individual workspaces can be depended upon in other contexts and projects, like building blocks.
4. Reusable components: From the outside world to us
When structuring your application as microservices, one can more easily slot in and exchange parts as needed. I have been thinking of using Lust as a CDN server, while perhaps using something like rauthy for authentication. Taking advantage of projects tailor-made for these specific things will mean that those parts will likely be of higher quality than if we wrote them ourselves, while we can focus on our actual core product. We already have enough work on our hands. Why not use a thing that already exists?
In lieu of these upsides, I do not see any reason to not go ahead with working on these changes.