Introduction

In this article, I’m going to show you the RevoGain software architecture.

RevoGain is a web application that helps Revolut users calculate their stocks and crypto trading gains, and I started building it at the beginning of September 2021.

Hype vs. Reality

Have you ever been to a software conference and felt disconnected from all those hyped technologies that were presented so beautifully on stage? I certainly had.

Whenever I came back from a software conference and looked at my project codebase, I could see a large gap between what’s being proposed as the next big thing and the battle-tested software technologies my projects were built with.

On social media, there are lots of people who are talking about shiny new technologies that aim to solve problems I’ve never had.

Any technology has a purpose, of course. However, as software developers, our goal is to identify what’s the best way to solve a given business problem. Sometimes, a newer technology can be the right answer. But, most of the time, a boring technology might be what you really need.

What you will soon see is that my stack strives for simplicity. For instance, I’m not using Angular, React, or Vue on the front-end. Just HTML, CSS, and JavaScript.

There’s no reactive programming or reactive database access. Just JDBC-based access.

There is no Kubernetes, no microservices, no hexagonal architecture, no DDD, no CQRS, no Event Sourcing, no Kafka, and not any of the popular NoSQL databases. Just a three-tier monolith that uses MySQL.

All those technologies are certainly useful. However, they are not needed to build RevoGain.

Front-End Layer

Here’s what I used to build the front-end layer:

You can achieve a lot with plain HTML, CSS, and JavaScript. Most of the time, you don’t need anything else.

While Angular, React, and Vue have many advantages, in my case, choosing any of those would prevent me from launching the product into production in just two months for a very simple reason. I don’t know how to effectively use any of those technologies. So, it would take me quite a lot of time to become proficient enough to implement any possible front-end task with ease.

And, there’s no free lunch. The moment you adopt a SPA (Single Page Application) design, you have to know what you are trading off. For example, there are some lesser-known drawbacks to using Single Page Applications that make it harder to do SEO properly.

Therefore, for RevoGain, I chose something simpler that makes SEO or caching a breeze. Having used plain HTML, CSS, and JavaScript for over 17 years without any issue, I knew exactly that this is the right front-end stack I should use.

I’m also using jQuery for some JavaScript logic and Bootstrap to make sure the UI is responsive.

Back-End Layer

The boring theme continues with the back-end layer:

The first time I used Spring was November 2004. 17 years later, and I’m still using Spring.

The web layer uses Spring MVC and Spring Rest. The HTML pages are built dynamically using Thymeleaf templates.

The data access layer uses Spring Data JPA and Hibernate. Eating your own dog food is the only way. For 17 years, Hibernate has worked like a charm for me. Having seen people struggling with it was my motivation to write the High-Performance Java Persistence book.

When used properly, JPA and Hibernate are a wonderful combination that allows you to develop the data access layer extremely fast without compromising performance.

And, because I have other people working on the project, I set up Hypersistence Optimizer to analyze the JPA and Hibernate usage and trigger a build failure if a code change could affect application performance.

Database Layer

No surprise here as well:

I’m using Amazon Aurora for MySQL because it’s very easy to set up, handles backups automatically, and provides monitoring as well.

Now, Amazon Aurora offers both MySQL and PostgreSQL, and many of my readers believe that PostgreSQL is always a better choice. But, that’s not true. Both MySQL and PostgreSQL have pros and cons.

The decision of using MySQL was taken because of the following aspects:

• most of the data access is done via the Clustered Index
• MySQL can use a very large Buffer Bool and because it uses Direct I/O, there’s no double buffering
• the undo log is more compact in MySQL
• the Serializable mode is based on locking, and the probability of MVCC-based rollbacks is lower
• MySQL uses range locks, which are missing in PostgreSQL

So, while, in general, both MySQL and PostgreSQL are great database products, for this particular web application, MySQL is a much better fit.

That’s it!

I'm running an online workshop on the 20-21 and 23-24 of November about High-Performance Java Persistence.

If you enjoyed this article, I bet you are going to love my Book and Video Courses as well.

Conclusion

Architecture is by purpose. The goal of a software project is to turn a business idea into a working solution. The tech choice should resonate with the business goals. Otherwise, the project will suffer.

In my case, I was very interested in Time To Market. I don’t want to spend a long time building something the users won’t need. So, instead, I prefer launching rapidly and evolving the product based on real-life user feedback. The user knows best. The application is for the user, not for me. The user shapes how the project should be used.

Using a boring stack that I know very well allows me to focus on features rather than tech issues. In the first two weeks since I launched it, I managed to add lots of new features based on the feedback I got from the clients.

So, if you’re software architecture doesn’t resemble at all what the latest Technology Radars or software conference trends advertise, rest assured. In the end, what really matters is to have a working solution that can adapt to user needs.

Insert details about how the information is going to be processed

DOWNLOAD NOW