We've solved this problem by making the modules in the monolith only able to call each other from well-defined APIs, otherwise CI fails.
In the Java world both Spring and Guice are meant to do this, and if you have an ISomething you've got the possibility of making an ILocalSomething and a IDistributedSomething and swap one for the other.
This is generally a bad idea imo. You fundamentally will have a hard time if your api is opaquely network-dependent or not. I suppose, you’ll be ok if you assume there is a network call, but that means your client will need to pay that cost every time, even if using the ILocal.
It depends on what the API is. For instance you might use something like JDBC or SQLAlchemy to access either a sqlite database or a postgres database.
But you are right that the remote procedure call is a fraught concept for more reasons than one. On one hand there is the fundamental difference between a local procedure call that takes a few ns and a remote call which might take 1,000,000 longer. There's also the fact that most RPC mechanisms that call themselves RPC mechanisms are terribly complicated, like DCOM or the old Sun RPC. In some sense RPC became mainstream once people started pretending it was REST. People say it is not RPC but often you have a function in your front end Javascript like fetch_data(75) and that becomes GET /data/75 and your back end JAXB looks like
@GET
@Path("/{id}")
public List<Data> fetchData(@PathParam("id") int id) { ... }
Re:The Grug Brained Developer (2022)
by williamdclt on Wednesday June 18, 2025 @09:31AM
(#44309744)
I honestly think it's the only way outside of one-person projects (and even then...), you need _some_ design pressure.
Maybe the friction imposed to mess up the well-factored microservice arch is sufficiently marginally higher than in the monolith that the perception of value in the factoring is higher, whereas the implicit expectation of factoring the monolith is that you’ll look away for five seconds and someone will ruin it.
I think monoliths are not such a good idea anymore. Particularly with the direction development is going w.r.t the usage of LLMs, I think it's best to break things down. Ofcourse, it shouldn't be overdone.
Re:The Grug Brained Developer (2022)
by discreteevent on Wednesday June 18, 2025 @02:56AM
(#44307306)
> grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too
> I think it's best to break things down
Factoring system = break things down.
My grug brain conclusion: Grug see good microservice in many valley. Grug see grug tribe carry good microservice home and roast on spit. Grug taste good microservice, many time. Shaman tell of good monolith in vision. Grug also dream of good monolith. Maybe grug taste good monolith after die. Grug go hunt good microservice now.