You either read or write, you consume or produce, you use someone else’s technology or create it. You know that the hardest part is the second option (writing, producing, and creating), and I do not understand why software developers spend more time on the first than on the latter.
It is especially exciting when you finally bring to light something you have been working on for a very long time (years).
This happens to me with each and every one of my books, when you finally see the latest work in all Amazon stores and other platforms (like this small contribution I recently launched on Bitcoin), when I publish a new project, or when I finally put a project for a client into production.
For a few months now, I can say that a sufficiently mature Mantra release exists to be used in production projects.
For the good and the bad, as a professional software developer and team/project leader for more years than I care to remember, I have often had to work on large, complex projects that had to evolve a lot and with considerable difficulty over their lifecycle.
Likewise, I have also sometimes been hired to assess the quality of a software project and prescribe what needs to be improved so that the mudball (technical debt) does not continue to grow until the project becomes unviable, unmanageable, or unmaintainable, when it has not already had to be thrown away and restarted from scratch, to the dismay of managers and frustration of developers. This usually happens not only because of a lack of professionalism in the code, but also due to organizational deficits and other issues.
I assure you that detecting all of the above is neither easy nor straightforward.
In other words, I know firsthand why software tends to decay, how and why technical debt accumulates, and what the bad habits of developers do that make a project expensive to maintain, as well as the organizational bad habits that contribute to all of this.
If you have read any of my books, you already know that I talk about these issues continuously and in depth.
And I know this because I am one of the first to have made (and suffered) every possible mistake, but always with the purpose of not repeating the same mistake more than once.
It is no coincidence that one of my books, “Legacy Code: Cómo modernizar en catorce pasos código heredado o proyectos software que han crecido demasiado rápido” (“Legacy Code: How to Modernize In Fourteen Steps Legacy Code or Software Projects that Have Grown Too Quickly”), suggests how to improve the quality of a legacy software project in a series of steps and how to modernize it.
Mantra is a framework based on Node.js that forces a project to be structured correctly, based on radical componentization and extreme decoupling between them, while allowing high testability and reusability of each and every component forming part of a project, among many other features.
Mantra was not created to compete with other proposals that have existed for much longer (such as Next.js, which I love, by the way), but to respond to what I consider a viable way of approaching software development to minimize the technical debt that does so much damage to business competitiveness, especially in large projects that will evolve a great deal, are high-performance and scalable, and must be as competitive as possible.
To put it one way without sounding too pretentious: Mantra implements a software development paradigm.
The development of a project with Mantra follows a series of principles that I have structured as well as possible in a whitepaper that you can read in English and Spanish.
Perhaps the whitepaper on which Mantra is based will surprise you, because, in reality, it is more than just identifying principles to follow; it is, in truth, a change of paradigm for approaching the development of professional, large, evolvable, and scalable projects.
It is my small contribution to software engineering, although, believe me, many of those principles are simply well-known best practices in our sector that I have grouped into a coherent set and implemented in Mantra so that projects can grow and evolve (with as-yet-unknown requirements) without accumulating technical debt.
Some of these principles include:
- Radical componentization: a component is the fundamental unit of code in a project and, by definition, is small and reusable, just a few hundred lines of code.
- A component implements a very specific functionality and exposes it to the rest of the project.
- By definition, a component is completely decoupled from another (dependencies are soft, not hard).
- High-level functionality is implemented by orchestrating lower-level functionality.
- The persistence of a component’s data is transparent to it and does not create a strong link.
- A component defines minimalist data models (just one, two, or three entities). Yes, read that carefully: nothing like large, tightly-coupled databases that are impossible to maintain, migrate, and evolve. In fact, Mantra allows multi-repository applications (that use several data sources transparently).
- A project is based on a set of applications that communicate with each other.
- Project migrations are frequent and incremental.
- etc.
The practical consequences of applying the above principles are incredible: more evolvable projects, simpler and less expensive to maintain, greater reusability, better testing, and scalability.
With Mantra I have already built several projects for various clients, including Hub de Libros as well as the project’s own website, of course.
And it works: the effort required to evolve each project (implementation of new requirements) is small if the concepts above have been followed, maintainability is extraordinary, and developer satisfaction is high because we spend most of our time… implementing features or modifying existing ones.
Although it can already be used freely, Mantra is a more ambitious project in which we will keep publishing downloadable components, secure and tested, with common functionality, as well as complete projects that can serve as starting points for final, specific projects.
To be honest, I am excited about Mantra. I believe it is the most complex project I have ever done, and I hope to be able to dedicate much of my professional time to it.
How do you learn to build applications with Mantra?
The learning curve is extraordinarily short.
A great effort has been made to create comprehensive and clear documentation (for now only in English), and, in addition, demonstration projects are continually being published showing how to implement specific tasks, alongside constant publication of how-tos explaining in brief articles how to carry out specific tasks.
Mantra, like any software project, is a project in continuous evolution, in which performance improvements and enhancements to existing functionality are constantly introduced, but with the commitment that the user and the company using Mantra do not have to pay the cost of migrating to the new releases we launch, because, I insist, one of the objectives of Mantra is to reduce the cost of professional application development so that they are more competitive, and this is achieved from several angles.
As a framework, it emerged gradually and naturally from years of working on Node.js-based projects without fully convincing me of other frameworks that already exist, simply because I could not easily and naturally implement the principles above.
As CTO of Mantra, I trust that this contribution will be of great use to our sector, which is always evolving and always guided by that spirit of kaizen and continuous improvement.