4 ms·

> What programming language would you choose if you wanted to make a modular monolithic architecture? i'm sort of cheating, but: if you add more context, the d

by shoo 4y ago

> What programming language would you choose if you wanted to make a modular monolithic architecture? i'm sort of cheating, but: if you add more context, the decision will likely be easier. what's the architecture for? what are the key constraints of your context that you need to optimise for? is modularity the primary constraint, or is it secondary or tertiary to other concerns? e.g. if the architecture will be used to build engines for fancy AAA games, where memory bandwidth is a major consideration, maybe your choices are limited to C/C++ so you can squeeze the most out of the hardware, and make use of existing middleware. if your monolithic architecture needs to be adopted by a company that has 1000s of developers who are familiar with java, then maybe to make it easier to sell internally, it needs to be implemented in java, so the switch cost is reduced for teams who you're trying to convince to adopt it. if you're building some saas thing, then you are probably going to end up using javascript for some of it. if the architecture will be used by teams with large numbers of recent grads / junior devs to deliver projects or ship features, maybe it's best if the language doesn't contain too many huge foot-guns.

lucidguppy 4y ago
If you wanted the modularity of microservices, but couldn't use microservices and were forced to use one process - what would you use. We want to force programmers through the language to only go through services' public interface - and if possible prevent them from even knowing about the private data,classes, and methods of the module internally.
- shoo 4y ago
  If Go is a feasible option [1], each service could be structured as its own module, with all of its private data and types placed in packages inside the module's special internal/ package, which has special support from the compiler: > internal/ is a special directory name recognised by the go tool which will prevent one package from being imported by another unless both share a common ancestor. Packages within an internal/ directory are therefore said to be internal packages. https://dave.cheney.net/2019/10/06/use-internal-packages-to-reduce-your-public-api-surface https://dave.cheney.net/2019/10/06/use-internal-packages-to-... It'd be the responsibility of the owner of each service to opt-in and put private things in their internal/ package, and not expose them as part of the service's module's public interface to other modules. More generally, if you have a lot of influence over how your services are written and maintained, even for languages and tooling that doesn't give you a built-in way to enforce that external dependencies on private details of other components are not introduced, it might not be that hard to write a custom linter script to analyse all the imports in your project and fail the build if any change introduces a forbidden dependency. Re: running things in a single process. With Go, suppose you craft a number of services wrapped in their own packages with well-designed public interfaces, and all private details hidden via the compiler-enforced internal/ package mechanism. There are still scenarios where the modularity can be horribly broken, and the implementation details matter, especially if you're running everything on a single machine or in a single process: e.g. suppose the private internals of one service want to leak all of the TCP buffer memory or open all the file handles, that'll likely break the internals of some other service that is competing for the same shared resources. Similarly, suppose some internal code deep in the bowels of one service triggers a panic inside a goroutine that isn't trapped, then the go runtime will react by terminating the whole process, taking down all of your services. The language-level modularity doesn't give you a way to enforce that services running in the same process or in the same machine can't trash shared resources. [1] Go is a pretty good fit for writing backend web services, and less of a good fit for, say, shipping mobile apps, or prototyping machine learning algorithms.
  - lucidguppy 4y ago
    This is a great point - and its a widely used language.

by shoo 4y ago

lucidguppy 4y ago

If you wanted the modularity of microservices, but couldn't use microservices and were forced to use one process - what would you use. We want to force programmers through the language to only go through services' public interface - and if possible prevent them from even knowing about the private data,classes, and methods of the module internally.

shoo 4y ago
If Go is a feasible option [1], each service could be structured as its own module, with all of its private data and types placed in packages inside the module's special internal/ package, which has special support from the compiler: > internal/ is a special directory name recognised by the go tool which will prevent one package from being imported by another unless both share a common ancestor. Packages within an internal/ directory are therefore said to be internal packages. https://dave.cheney.net/2019/10/06/use-internal-packages-to-reduce-your-public-api-surface https://dave.cheney.net/2019/10/06/use-internal-packages-to-... It'd be the responsibility of the owner of each service to opt-in and put private things in their internal/ package, and not expose them as part of the service's module's public interface to other modules. More generally, if you have a lot of influence over how your services are written and maintained, even for languages and tooling that doesn't give you a built-in way to enforce that external dependencies on private details of other components are not introduced, it might not be that hard to write a custom linter script to analyse all the imports in your project and fail the build if any change introduces a forbidden dependency. Re: running things in a single process. With Go, suppose you craft a number of services wrapped in their own packages with well-designed public interfaces, and all private details hidden via the compiler-enforced internal/ package mechanism. There are still scenarios where the modularity can be horribly broken, and the implementation details matter, especially if you're running everything on a single machine or in a single process: e.g. suppose the private internals of one service want to leak all of the TCP buffer memory or open all the file handles, that'll likely break the internals of some other service that is competing for the same shared resources. Similarly, suppose some internal code deep in the bowels of one service triggers a panic inside a goroutine that isn't trapped, then the go runtime will react by terminating the whole process, taking down all of your services. The language-level modularity doesn't give you a way to enforce that services running in the same process or in the same machine can't trash shared resources. [1] Go is a pretty good fit for writing backend web services, and less of a good fit for, say, shipping mobile apps, or prototyping machine learning algorithms.
- lucidguppy 4y ago
  This is a great point - and its a widely used language.