3 ms·
The problem microservices try (tried?) to solve isn't about namespaces, it is about too tight coupling between code. Whether that tightly coupled code sits in a
by atoav 3y ago
The problem microservices try (tried?) to solve isn't about namespaces, it is about too tight coupling between code. Whether that tightly coupled code sits in a subdirectory or in a different repo doesn't matter.
It can be benefitial to maintain well defined interfaces at boundaries between certain parts of your code. It can also produce a lot of work and add complexity. But beyond a certain scale adding systemic boundaries and honoring them isn't something you should avoid.
Devs who do microservices just tend to go too far too early.
- corethree 3y ago>The problem microservices try (tried?) to solve isn't about namespaces, it is about too tight coupling between code. You can use folders to decouple code by making code private within that folder. Only publicize parts of the code with your languages version of exporting. Or you can make it private behind an entire new repo and behind an entire service. Only publicize parts of the code through api interfaces like http and make everything 10x harder for the sake of decoupling code.
- tored 3y agoMany languages misses that abstraction to make things private in a folder (namespace) hierarchy to outside consumers. This is something I like to see solution to (integrated with your IDE of choice)
- corethree 3y agoPython is the only one that I know of that does this. Additionally python uses private by convention: Just prefix the stuff with an underscore.
- atoav 3y agoSure there are tons of ways to decouple code. My point was however, that moving code into a folder doesn't automatically solve that coupling issue.
- corethree 3y agoWhat do you mean "sure?" If you said "sure" then you agree it works so why use any strategy that's 100x harder? I say again, use a folder bro.