4 ms·
> If the monolithic application is written in a language with sufficient encapsulation and good tooling around multi-module projects, then you can indeed have w
by gedy 3y ago
> If the monolithic application is written in a language with sufficient encapsulation and good tooling around multi-module projects, then you can indeed have well known and encapsulated interfaces within the monolith. Within the monolith itself you can create a DAG of enforced interfaces and dependencies that is logically identical to a set of services from different codebases.
So then, not Rails apps
- lemmsjid 3y agoYes, a good point, I think the more dynamic the language, the more one gravitates towards microservices as a problem solving tool, because you'd give up a lot of the value of the dynamic environment by enforcing strict rules. Though I'm seeing a lot of convergence between environments over time, which makes me think we're all headed towards a nicer future. For example in Scala, which does a lot of type inferencing, it's typical to tell the linter to require that public methods have explicit types, even though the compiler will reify them at compile time anyhow, because that makes the interface much more robust to refactoring. Meanwhile in a more dynamic environment, in Python it's getting more typical to use type annotations, and, similarly, to especially use them on functions that define a reusable interface. I figure that the ideal languages in the future have module-level systems where they can define strict interfaces across modules, but then get as crazy and dynamic as they want inside of the modules.