This made me chuckle for a good 10 minutes!

At work we’re currently in the last layer of the iceberg with 35+ microservices, with ten different Kubernetes instances for different uses and a supported OnPrem version.

It is bit of a learning curve and we definitely have two “mono-services” that we’re actively braking down due to it accumulating seven years worth of different ideas and implementations.

I think currently I’m still heavily in favor in microservices in a project of our scale as it easily let’s us enhance, trash, or reimplement different areas of the app; but man is it a pain in the ass to manage sometimes 😂

Neovim with coc-rust-analyzer.

There’s also coc-rls.

Given this project has been around for many years, (looking at their releases), I wouldn’t say it’s “early” to modularize their code. It’s very common practice to abstract out / move commonly executed code into their own packages and modules to allow ease of reuse across the app. This way if an entire subpackage needs to be moved or deleted, all related code could be affected at once and code which references it, simply needs to be edited. Typically these places to edit are much easier to handle since most of “calling code” wouldn’t touch the modularized / abstracted code, only their callables.