Sometimes it is better to reinvent the wheel

It is time to share another work experience with the world :).

This year 2022 has been a thrilling ride with Linus Digital Finance solving problems and making life easier for our Investors. The craziest part was the challenge to enhance the open-source project “Fineract” for our business model.

Why Fineract?

One of the main components of our business model is lending loans and managing the Repayments. One of the things Fineract also does is manage Loans and Repayments. However, this was not only our selection criteria but also preferably an application built using any of the JVM languages. These requirements made us choose Fineract over the other alternatives.

Positives

1. Liquibase support — Integration of Liquibase helps to have a clean database migration.
2. Supports the latest Java versions.
3. Kubernetes Deployment and service charts or YAML files are available.
4. Clear Documentations.

Now let me try to explain after almost a year, why I think “Sometimes it is better to reinvent an MVP model”.

Fineract Build times

Everyone knows why management and developers love microservices. Some of the reasons are

1. The power to scale teams much faster
2. Releasing things faster by making a small number of resources.
3. Clearly defined boundaries.

Fineract as a monolith with more than five modules uses Gradle for the build process. The whole build takes 15–20 minutes to produce a jar file.

Integration Tests

Integration tests are run along the build using “Cargo Plugin”. ie, Runs the jar application as a process using the cargo plugin and then runs the series of tests against this jar. Imagine running more than 75 SQL migrations every time in your CI/CD pipeline when a build is triggered.

No Clear Boundaries

The modules are reused in every other module and make the whole codebase tightly coupled. This always makes me sleepless nights when thinking about splitting this monolith into microservices in the future.

Never-ending while loops

Do not be alarmed when your HTTP request does not get finished after a couple of seconds. There are while loops like this `WHILE(TRUE)` at least in 2–3 java classes without max tries. This potentially causes thread starvation sometimes. Although Integration tests can show a 100% success rate, certain property values misconfigurations can lead up to this :(.

God Objects everywhere

God Objects or classes can be seen everywhere. Single Responsibility Principle discarded in high regard.

class A extends B{
}
class B extends C{
}
class C extends God{
}
class D extends God{
}
class Z extends God{
}

Debugging hell

God objects explained above are one of the main reasons why we will experience Debugging hell. Forgetting where we started or forgetting what we came through is normal in Debug mode. There are quite a few reasons for that.

1. Class methods have more than 100 lines of code.
2. The single-class method does multiple things even though the name says something different.
3. Propagating back and through to GOD classes doing so many things.
4. Similar method names but entirely different business logic.

What did we do?

Realizing and prioritizing technical improvements helped us to achieve better and faster results in releasing new features using Fineract.

Some of the improvements we made are,

1. Improve Gradle tasks by compiling only modules which has code changes (helps productivity during development phase).
2. Creating one sql data definition migration of fineract database instead of 75 sql migration files.
3. Capability to choose which modules to be loaded during the application startup.