[threeseed]

Maybe you've only worked on small projects.

But I've never worked on a monolith project that I could run entirely locally.

And this idea that APIs are slow, unreliable and unable be to be strongly typed is nonsense. This is 2023. We have plenty of tooling and techniques to make this robust.

[The_Colonel]

The (monolith) product I currently work on has about 200 engineers working on it (backend + frontend + devops). I'd say it's of medium size, certainly not small. And yes, we can run it locally easily. The monolith starts up in like 20 seconds which I consider quite acceptable.

There are few narrowly defined responsibilities which are handled by dedicated services, and it is often more awkward to get them working locally. But because they are so specialized, you need them only rarely.

> And this idea that APIs are slow, unreliable and unable be to be strongly typed is nonsense.

Network APIs are inherently slower and more unreliable in comparison to an in-process method call. Some typing solutions are there, but they are way more awkward (and in some ways weaker) than statically typed monolith interfaces.

[plugin-baby]

> I've never worked on a monolith project that I could run entirely locally.

What are some examples of monolith components that couldn’t be run locally?

Im guessing third-party integrations, but perhaps there are other things.

[threeseed]

For a monolith it's having to run the entire platform locally to fix one bug.

That includes databases, caching, auth, ML models, mock API endpoints etc all pre-populated with sample data then the actual application which for complex, JVM based ones can often fail to launch if there isn't enough memory to pre-allocate.

Many systems I have worked on all of that would simply not fit on a 16GB MBP.

[deterministic]

I work on very large monoliths all the time. The kind of code that runs international airlines and airports. I run it locally in a VM. No problem.