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.
Comments
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.