Comment by the__alchemist 3 days ago
On the theme of several other responders:
I don't want microservices; I want an executable. Memory is shared directly, and the IDE and compiler know about the whole system by virtue of it being integrated.
> But, unless you have some way of enforcing that access between different components happens through some kind of well defined interfaces, the codebase may end up very tightly coupled and expensive or impractical to evolve and change
You are describing the "microservice architecture" that I currently loathe at my day job. Fans of microservices would accurately say "well that's not proper microservices; that's a distributed monolith" but my point is that choosing microservices does not enforce any kind of architectural quality at all. It just means that all of your mistakes are now eternally enshrined thanks to Hyrum's Law, rather than being private/unpublished functions that are easy to refactor using "Find All References" and unit tests.
> through some kind of well defined interfaces
Every compiled language has the concept of "interfaces", and can load even compiled modules/assemblies if you insist on them being built separately.
The compiler will enforce interface compliance much better than hitting untyped JSON endpoints over a network.
I love the idea that I can compile all my functionality including HTML templates, javascript, and CSS into a single albeit huge Golang binary.
I have never done this yet.
But I love the idea of it.
You can already do this with Deno Compile
But that uses Javascript and Typescript, and I don't know those.
I guess I need to learn Javascript at some point.
This is what I'm doing with my side project! A set of personal smart picture frames for me and my partner. One executable does:
- the uploader API
- the uploader UI
- the frame API
- the frame UI
UIs are SSG'd with solid-js and solid-start then served with gin.
It's really fun.
I loved uberjars back when I was writing Scala. I don't miss much about the JVM, but I really miss having a single executable I could just upload and run without having to pay attention to the environment on the host machine.
Yeah, but building a docker image tends to be a lot heavier weight and slower, in my experience, than uploading a single jar
Probably works OK for a small project with a close knit team of skilled contributors where there's some well defined structure and everyone has sufficient high level understanding of that structure to know what kinds of dependencies are or are not healthy to have.
But, unless you have some way of enforcing that access between different components happens through some kind of well defined interfaces, the codebase may end up very tightly coupled and expensive or impractical to evolve and change, if shared memory makes it easy for folks to add direct dependencies between data structures of different components that shouldn't be coupled.