First anniversary of Minum v1

There are so many essays written on how simplicity should be favored over complexity. That microservices, Kubernetes, and even the use of separate frontend applications (rather than using server-side rendering) are overkill for most projects.

With those ideas as the guiding star, Minum began development in December of 2021. Version 1.0.0 was released almost a year ago, and the project has entered a state of stability. The primary focus remains making available a zero-dependency minimalist Java web framework for developers of monolithic, server-side-rendered web applications.

A guide on making contributions was recently added to the project.

if any of this piqued your interest. I would certainly value the insight of other practitioners.

Notes:

These essays argue against the trends of unnecessary complexity that have become the table stakes in the programming industry. Each paragraph is a link back to its source text.

The audit revealed an interesting pattern, where many startups experienced a sort of collective imposter syndrome while building straight-forward, simple, performant systems. There is a stigma attached to not starting out with microservices on day one - no matter the problem. “Everyone is doing microservices, yet we have a single Django monolith maintained by just a few engineers, and a MySQL instance - what are we doing wrong?”. The answer is almost always “nothing”. https://renegadeotter.com/2023/09/10/death-by-a-thousand-microservices.html

It can be amazing how far a small set of technology choices can go. The answer to this question in practice is almost never “we can’t do it,” it’s usually just somewhere on the spectrum of “well, we could do it, but it would be too hard” [4]. If you think you can’t accomplish your goals with what you’ve got now, you are probably just not thinking creatively enough. https://mcfunley.com/choose-boring-technology

StackOverflow uses ASP.NET. So you can complain all day about public static void main, but have fun setting up 500 servers. The downsides of dynamic languages are real, expensive, and permanent. https://www.teamten.com/lawrence/writings/java-for-everything.html

There is even more time spent on simply understanding the system, which could better be spent continuing to develop it. While I would never tell any engineer that time spent understanding a system is time wasted, I would definitely warn people away from prematurely adding these levels of complexity until they know they need it. https://riak.com/posts/technical/microservices-please-dont/

People newer to the industry might never have built a server-side rendered app, so it's not an open question for them. As a result, for most client-side rendering is uncontroversially the 'right' way to build software. I think they're wrong: server-side rendering is more often the better choice. https://www.timr.co/server-side-rendering-is-a-thiel-truth/

By adopting Microservices or micro-frontends, you’re shifting the complexity, not removing it. In some places the shift is worth it, but if your system isn’t large enough, your teams aren’t numerous enough, and the problems you’re facing aren’t coming from coordinating huge numbers of developers, then splitting your application up into lots of tiny pieces will likely create more headaches than it eliminates. https://www.simplethread.com/gasp-you-might-not-need-microservices/

Simple designs for a racing car offer a huge advantage over complicated rivals, because they are easier to maintain. A complicated design has more things that can go wrong, and when they do go wrong it is more difficult to design and fix. This should be painfully familiar to anyone working in software engineering, and yet as a whole we keep producing over-complicated solutions. https://web.archive.org/web/20170228054121/http://richardwellum.com/2017/02/simplify-then-add-lightness/

This premium, essentially the cost of managing a suite of services, will slow down a team, favoring a monolith for simpler applications. This leads to a powerful argument for a monolith-first strategy, where you should build a new application as a monolith initially, even if you think it's likely that it will benefit from a microservices architecture later on. https://martinfowler.com/bliki/MonolithFirst.html