The product development team at FA held another internal hackathon at the end of January. For three days, enthusiastic participants got a break from the usual development activities to work on something new and different. For three glorious days, we could leave the rigors of a SOC-certified development process behind and simply try things out. It’s a nice change of pace.
As we wrote in a previous blog entry, some of the things we work on during hackathons end up becoming part of the FA Platform. Although I can’t guarantee that the features described below will make it to an official release, I thought it would be nice to give you, our dear readers, a glimpse of the kinds of things our developers chose to work on when it was entirely up to them.
Market prices microservice
Performance and scalability of the FA Platform are major focus areas for the product development team. One of our hackathon teams tried out whether we could improve the platform’s scalability by introducing a microservice dedicated solely to market prices. The idea was that a Quarkus-based microservice could efficiently serve all our applications’ market price needs optimally. Such a service could flexibly adapt to variable workloads and reduce the overall load on the database by keeping the latest set of prices in memory. After all, the latest prices are what we most commonly need.
So, what did the team accomplish in 3 days?
- They built a new Quarkus microservice.
- They added caching to support retrieval of the latest prices from memory.
- They added REST and gRPC endpoints.
- They even had time to try out a new type of database called InfluxDB that specializes in time-series data.
How did the microservice perform? The team ran some tests to determine how long it takes us to fetch 100 prices using REST. What if we use gRPC instead? What about the entire price history of a security? How does MariaDB stack up relative to InfluxDB?
In our tests, InfluxDB didn’t provide a consistent advantage over our current database technology (MariaDB), and gRPC didn’t offer a consistent benefit over REST – it depended on the setup and test case. As far as pure speed was concerned, the microservice was fast but did not provide an advantage over loading data from the database.
The purpose of this microservice was mainly to improve scalability and performance under heavy load rather than speed in a vacuum. So, how did the market prices microservice perform in terms of scalability? The answer is… that we don’t know yet. Although the team achieved a lot during the three days, they didn’t have time to integrate the microservice into a real environment to see how it performs with heavy concurrent use. Whether or not we can demonstrate significant scalability benefits will determine the future of this microservice. Time will tell.
Keycloak.X
The FA platform uses Keycloak for identity and access management. Keycloak is currently working on something exciting: Keycloak.X. One of our hackathon teams looked into the new-and-improved Keycloak version to see what the Keycloak developers have in store for us. They fired up the preview-release of Keycloak.X, connected it with the FA Platform, crossed their fingers, and…
Rather quickly and easily, they got it to work! Keycloak is a crucial part of the security of the FA Platform, so we need to keep on top of our Keycloak version upgrades. Now, thanks to three days of investigation and compatibility tests, we have a good idea of what it will take for us to upgrade to Keycloak.X once a production-ready version becomes available.
Global push notifications
Wouldn’t it be nice if you got a popup notification as soon as specific things happen in the FA platform? For example, what if…
- Someone assigns you a task?
- Reconciliation material arrives and is processed, but found errors?
- Your customer signed the subscription form that you’ve been waiting for?
- Your background report generation finished?
Instead of anxiously waiting and refreshing your task list in FA Back from time to time, one of our teams looked into the possibility of popping up push notifications when these things happen. Within three days, the team built a messaging-based solution that any part of the FA platform can use to send push notifications to a specific user or group of users. The mechanism worked across the various parts of the FA platform: a notification about FA Back reconciliation mismatches successfully found the user even though they were using our Fund Management application at the time.
In conclusion
New technologies were examined, corners were cut, demos were shown, and coffee was consumed. Most importantly, we learned a lot and had fun, and maybe some of these features will be included in the FA Platform in the future. I’m already looking forward to our next hackathon later this year to see what more we can come up with when we disrupt our regular work and take some time for innovation.
