Haven't had time to dive into the code yet, but the write-up is very thorough !
A couple points though:
- i wish you had made it clear from the start that the architecture applies to individual applications / services.
I wondered if "components" were made to represent only libraries of functions, or if they could be their own server running along side other services. You need to wait for the very end to get the idea that a polylith distributes / microservices architecture means "many polilths next to each other".
Which means that polylith might help organize the _code_ of a microservices monorepo, but will be of no help with the _execution_ problems of it (eg where should the data live, how many services do you have to traverse, how do you deal with desynchro and caching, etc... In my experience those are the thorny problems, not so much how your libs are laid out - but maybe that's because we already use similar ideas coming from "clean architecture", "hexagonal", etc..
- I am right to understand that most code in "components" should be concerned mostly with business domain, and free of "big" frameworks (spring / rails / etc..) and that only "bases" should be concerned with that ?
- what is the story when you need to fake a component that represents a distributed service ? The "component" folder will have an API,and an implementation that targets the real service ; but should it also provide a "fake" implementation ? Or would it be a different component sharing the same API ?
- Are there sides of the architecture that depends on being done with a dynamic language like closure ? Have you actually tried it with other languages ?
Thanks !
A couple points though:
- i wish you had made it clear from the start that the architecture applies to individual applications / services.
I wondered if "components" were made to represent only libraries of functions, or if they could be their own server running along side other services. You need to wait for the very end to get the idea that a polylith distributes / microservices architecture means "many polilths next to each other".
Which means that polylith might help organize the _code_ of a microservices monorepo, but will be of no help with the _execution_ problems of it (eg where should the data live, how many services do you have to traverse, how do you deal with desynchro and caching, etc... In my experience those are the thorny problems, not so much how your libs are laid out - but maybe that's because we already use similar ideas coming from "clean architecture", "hexagonal", etc..
- I am right to understand that most code in "components" should be concerned mostly with business domain, and free of "big" frameworks (spring / rails / etc..) and that only "bases" should be concerned with that ?
- what is the story when you need to fake a component that represents a distributed service ? The "component" folder will have an API,and an implementation that targets the real service ; but should it also provide a "fake" implementation ? Or would it be a different component sharing the same API ?
- Are there sides of the architecture that depends on being done with a dynamic language like closure ? Have you actually tried it with other languages ?
Thanks !