java programmer

In the previous post, I described the Family Finance Tracker application in terms of functionality. The scope of works of the first version, which will be public, is already closed. At the moment I’m working on refining these functionalities. So I think that the time has come to share with you the information on how, technically, the application has been built, and how it happened that one programmer was able to do a working application simultaneously for Android, iOS, as well as a version running in a web browser in 3 months.

The post is quite technical, so people not related to IT may not be fully interested in this subject. If so, I apologize in advance. However, I tried to explain the issues that I am touching quite simply, so I think that these people can also find something interesting here.

My experiences

In order to fully explain my technical decisions, it is worth mentioning what I do professionally.

For about 10 years I have been working as a programmer in one of the insurance companies. On a daily basis, I deal with a product system for life insurance, which is quite related to financial settlements as well as to investments. I develop in Java, we use SQL database to store data and we have recently started using the Angular 5 framework to build the user interface. Additionally, we use frameworks such as Spring and Hibernate.


When we came up with the idea of ​​building our application to manage the household budget, we began to wonder how big the scale of the solution will be, which we plan to do practically only with our own resources – at least initially. The conclusion was,  that we can’t afford to use completely unknown technologies, because it would significantly prolong the preparation of the so-called MVP (Minimum Viable Product – the minimum version of the application that meets the basic needs of Users and is the basis for further development).

We wanted to prepare a tool that we could use ourselves as soon as possible, because as we wrote in the first post, the use of Google Docs has become quite a burden for us. We also wanted to let people who could be interested in such an application know that we are working on it at an early stage.

Our main assumption is that the application must be cross-platform. It must work in a web browser, but also on mobile devices with Android and iOS systems. It is also necessary to have full, immediate and convenient data synchronization not only between different devices, but also between multiple users, so that all family members can use the application at the same time.

As a standard, to prepare a solution of this type, we need:

  • “backend”, ie an application running on a remote server, accepting requests from all users, from all platforms (browser, mobile devices)
  • database
  • “frontend”, an application in a web browser
  • Android mobile application
  • iOS mobile application

At first glance, you can see a lot of work – four separate applications and a database.


spring boot


As I wrote earlier, I develop in Java on a daiy basis, so the first choice was for me to use Spring Boot (https://spring.io/projects/spring-boot). This solution is certainly known to all Java programmers. It allows you to use all the benefits of the Spring framework, while providing a quick and convenient configuration. This tool is very often used in both small applications and those of the Enterprise class. It is very well tested, stable, has a very large community, which provides quick support in case of problems. However, I do not conceal that one of the most important criteria that decided about his choice was that I know them quite well, so the “entry threshold” was very low – I could immediately focus on the functionality of the application, not on the “fight against technology”.



I had a big dilemma,while choosing a database. As a standard, I use relational databases (SQL), however, various types of object databases (noSQL) are getting more and more popular, which I hardly had any contact with. It was very tempting to play some of these databases on the occasion of creating a new application. After reading a number of articles on the Internet, and analyzing on forums of many wars between supporters of both approaches, I came to the conclusion that I put on SQL.

The type of data that will be stored in the Family Finance Tracker application will be strongly structured. NoSQL databases are more suitable for applications where the data pattern is not clearly defined and rigid. So common sense won. I decided on the PostgreSQL database, which is one of the most popular SQL databases. In addition, there is a very large selection of hosting services and “clouds” that Postgres offers in their services.

Frontend, Android, iOS, PWA


The first plan assumed that at the beginning a browser application would be created using the Angular 6 framework. I wanted to work on the Android version in parallel, because here I had some experience. I thought that I would leave the iOS version for the very end, especially since I did not even have any Mac, without which the iOS version can not be published.

However, by some chance I came across the IONIC framework (https://ionicframework.com/), which supposedly allows you to write one version of the application and run it in the browser, but also to compile it to the native Android and iOS application. Additionally, you can prepare so-called PWA (Progressive Web App), which can be added from the browser level to the main screen of the phone and will behave practically the same as the native application.

I have been quite skeptical about this type of solution so far, but the vision of writing only one application code for all devices has spoken to me quite strongly. I did a little “research” on the Internet. It turned out that the framework is quite popular, there were already many sucessful implementations of various types of applications.

When I started work, the stable version was IONIC v3. At the same time, however, the first beta version of IONIC v4 appeared, which introduces many changes, sometimes breaking backward compatibility with previous versions. So I did not want to think that when I decide to use the stable version a moment later, I will have to migrate the application to version 4. I took the risk and started to write in a not-so-stable version right away. I found that before the work is very advanced, the framework will stabilize. An additional argument was that IONIC v4 allows writing in virtually pure Angular 6. You can use most of the Angular packages and libraries.

Looking back in time, I can say that it was a very good decision. At the beginning I had a lot of problems. There were all kinds of strange errors. I spent a lot of time looking for them in my code, and several times it turned out that they were errors in the IONIC itself. Fortunately, in most cases, it was enough to do an update for the next beta and the error disappears.

However, I have found that the approach – one code, all platforms, in this type of applications really works. It saved me a lot of work. Thanks to this, by adding a new feature in the web application, it is immediately available on all platforms. The perfect solution … 🙂



In applications of this type, security of Users data is extremely important. Creating an authentication mechanism that meets all security standards is not only very time-consuming but also very complicated. That’s why I also decided to use the ready solution provided by Google – Firebase.

In one tool we get the possibility of logging in through the majority of social media, as well as using an email address. Firebase provides good support for both Angular (also IONIC), as well as for Java and Spring. Thanks to this, I was able to prepare appropriate security relatively quickly.


google cloud

Two solutions we were talking about here. Our dedicated server or hosting “in the cloud”. Each of these approaches has its pros and cons. At the moment the second option won. I decided to host Google Cloud – both the database and the backend and browser application itself.

The main factor was that in the future, if the number of application users increased, in a simple way I will be able to scale both the database and the application itself. However, I must say that this is not as simple solution as it is advertised.

It took me five evenings to migrate the application from my own server, which I had a trial version on, to the production cloud. Although, all the tutorials and documentation provided solutions that should work “on the spot”, my application did not want to run. Prepare dedicated, custom installation scripts for Docker helped in this case. Docker is a platform container for applications used by Google Cloud.

Summing up, currently hosting in Google Cloud is already working very well and stable, but there is one problem – costs :-). This is not a cheap solution. Separately you pay for the transfer, separately for the number of database instances, separately for the number of application instances, separately for each processor core used, separately for Firebase to login, and so on … In general, the method of billing is quite complicated and the price is not the lowest. At the beginning you get $ 300 to use, but this money disappears quite quickly, even with a negligible load on servers 🙁


Technology choose of is never simple, with these types of projects. Different arguments follows each. Erroneous decisions will last to the end, because you can rarely afford to rewrite the application from the scratch. There is always need for compromises, especially if we have limited resources at our disposal. Judging by the pace of application development, which in my opinion is quite good, the choice was good. I have decided on popular and proven frameworks (even IONIC, in which a large part is very popular Angular), so in the future it may be relatively easy to find volunteers to help. If you have any additional comments or thoughts, please share them in the comments.




Leave a Reply

Your email address will not be published. Required fields are marked *