by bobkazamakis on 7/12/2022, 12:55:30 AM
Focus on how you wish to share your code, and what features you need to deliver. If you're developing multiple small applications, it might make sense to build some re-useable core libraries after you've assembled the first one (do it too early and you'll be trying to 'bake an apple pie from scratch').
Need variations and reuseble front-end components? Package em up and take advantage of es modules.
Need to share common business logic? Package it up and share ruby modules.
At a certain point, you'll find domain boundaries within these, and be able to split them based on their use (delegate authN/Z to an sso "service").
Microservices (when not taken to an extreme) help build a pathway to re-useable code, much like TDD helps you write code that doesn't abuse side-effects, static classes, etc.
Don't split them out too early or you'll spend all your time keeping all these dependencies in parity - don't want to serve a raw steak or a burnt one.
by rhacker on 7/12/2022, 12:52:12 AM
Personally I would make that separation even if there is just one developer (i.e. me).
When it comes to team size, if you're building a team and a SaaS app, what size team would you want a generic SaaS app as a Monolith vs team size for SPA + API backend? What impact would available team size have on architecture decisions? E.g. a team of 2-3 vs a team of 12 vs 30.
I think the Google/Facebook/AirBnB/etc way of doing things isn't suitable for a lot of small teams, however it is the latest hot tech that always seems to get implemented in early stage startups. How should available team size impact technology choices? Any rules of thumb here?