One of our clients showed interest in the development of a framework with the goal of making it easier to create financial technology applications. We’re going to provide you with highlights of the entire development process – from our original assumptions to the finished product. We’re also going to show you just how much faster it is to create fintech apps with the help of a framework like this.

High-level framework – what exactly do we want to develop?

The basic definition of a framework doesn’t necessarily explain what we’re planning to accomplish here. So let’s dig a bit deeper. Most applications, be it fintech apps or any other, consist of some business logic (workflows), business data models, and UI components that represent them.

While the business logic of each app is unique, there are lots of features that most apps have in common (e.g. authorization, database, security, administration panel).

When we narrow down the apps to a specific industry, like financial technology, the number of common features increases even further. Thus, making it potentially viable to create a high-level framework, in which all the common features as well as the basic frontend can be created with little to no coding. The goal of such a framework, of course, is to speed up the development of fintech apps. One can quickly create MVPs or even full-fledged products faster and cheaper, getting to the point where they can test their business idea in practice much faster, without compromising the future stability and scalability of their solution.

Fintech app framework – business requirements

The framework will be created with a couple of assumptions in mind:

• The framework will be focused on specific functionalities. The design is secondary – only basic customization will be available, such as changing colors or logo.
• The main goal of the framework is to enable very fast development of new fintech apps, so they can be offered to clients who want to introduce a new product quickly (e.g., to secure a new market niche or to test an MVP).
• The high-level elements that require no coding will be defined via forms, tables, etc., using a simple interface.
• For the most part, for any app created using the framework, only its business logic has to be written from scratch.
• The efficiency of a resulting app is a high priority. 

Technical assumptions for building a fintech app

Here are some aspects we thought about long before we started actual development. A lot of them would greatly change as the concept matured over time.

• Performance – since we prioritize efficient performance and modularization, we thought about using service-oriented architecture. We would also synchronize as much data as we can between services so that we can limit the number of queries.
• Data management – since our system needs to handle entities that will be defined outside of it, the best idea would be to give control over it to UI. That’s why we thought about using something like GraphQL.
• User interface – open-source JavaScript frameworks such as React or Angular are perfect for creating high-performance interactive user interfaces. Besides, our team has some great experts in these areas.
• Security – one of the main considerations is also the security of our apps. We could potentially use ready-made solutions such as Keycloak or Gluu.

That’s what we did know before we really got started. Now, let’s see what happened when our ideas met reality.

Approach to services

We decided to build some of our crucial services (security, data manager) as gateways to external services. By doing this, we were able to easily replace whatever custom solutions we were going to implement with ready-made solutions, should such a need arise. Each service had its own repository, container, and contract.

When it comes to flexibility, each service needed to be extendable and fully configurable. By using YAML configuration files, we were able to set our workflow, mailing, or UI services to look for code outside of them. This allowed us to ship with some predefined features, but still retain the option to write some custom code for a specific client.

Data management – taking data sync to the next level

Originally, we planned to use GraphQL for data fetching. This solution makes it easy to push data to the client in real-time in response to events by using subscriptions. You can also easily decide what data should be available to which services and parts of UI.

However, since we also wanted to sync data between services and optimize the number of queries, the solution proved insufficient. Instead, we used Tesseract – a custom data-fetching library, which uses the standard approach of querying specific data. We make it possible to subscribe to a specific query and then get information about every change of that subset of data – the true real-time processing through WebSockets.

The solution uses the publish-subscribe pattern, which means that there’s an event bus between services. Each of them uses the bus to send data about any changes to Tesseract, which in turn sends the information only to those services that find it relevant. At the same time, according to the CQRS pattern, we employ different methods for reading and updating data – services update the database, but it is Tesseract that serves as a way to read the current state of each piece of data. This mechanism proved to be very efficient and made apps based on our framework work fast, responding to any input in real time.

Tesseract – the only data-fetching library of its kind

The project’s custom data-fetching library Tesseract really does deserve a couple of extra words. Why? Because there isn’t another solution quite like this one on the market. The reason why it was developed in the first place is that no existing ready-made solutions (such as Prism, DeepStream, or Hazelcast) met all of the project’s requirements.

Tesseract functions as a unified data access layer, which connects multiple data sources (databases, message buses, third-party services, etc.). It uses the concept of “live queries” to optimize data transfer and increase the performance (quick response with data snapshots) of all the apps based on it. Unique features include real-time cache, multi-factor authentication and authorization, and plenty of possible third-party integrations.

Switching from open-source JS frameworks to Ext.js

In order to build interfaces for our fintech apps, we originally planned to use React or Angular. We still believe that each of them could do a great job. However, we eventually decided to go with Ext.js. – a proprietary JavaScript framework from Sencha.

For large business clients, especially in the area of financial technologies, it’s quite typical to ditch popular open-source solutions in favor of proprietary technologies.

Aside from legal and practical issues of using open-source technologies in this area, proprietary software such as Ext.js is usually backed by a large company and provides professional support and very well-written documentation. As a result, it seems more trustworthy for financial institutions. We made contact with the Ext.js team and quickly got up to speed with it. We were satisfied enough to back it. And so it was Ext.js that would power the user interface of apps made with our high-level framework. In addition to that, Ext.js also supports Internet Explorer 8 – a few projects still require such support, but in the world of finances it’s not that uncommon at all.

On a side note, it’s worth it to say that the way we implemented Ext.js makes it easy to replace it with React, Angular, Vue or any other major JavaScript framework, should it be necessary. We made it so that the backend sends information to the client containing a structure that describes a given user interface. Subsequently, Ext.js transforms the data into its components. It’s fairly easy to write code that would transform the structures into React/Angular/Vue components instead. We could also write a special SPA that takes input from the services and builds a user interface out of it using any given JavaScript framework. 

Still, we appreciate just how many things simply “come out of the box” when it comes to Ext.js.

A reactive approach to security – the limits of Keycloak

As previously mentioned, we considered a variety of ready-made centrally-stored security solutions. We spent the most time with Keycloak. We went as far as testing a full integration of Keycloak with our system. However, we eventually decided to build our own security system based on ABAC (attribute-based access control). Why? There are two main groups of reasons:

• Performance-related –  Keycloak works a lot like a REST API. As a result, it was difficult to ensure that once we change something in its panel, the change would be immediately reflected in the user interface. One of the requirements of our software was for any change of state to be reflected in real-time. Ultimately, Keycloak would be nothing more than a database in our implementation – we would only use a fraction of its real potential.
• Client-related – There are many small issues here, but primarily most clients want their security administration panels to be built into their custom solution. The idea that employees would need to log into an external application for such reasons seems, for them, suspicious and troublesome. Keycloak’s API didn’t provide enough features for us to completely bypass their panel.

Results

As you can see, building a high-level framework flexible enough to truly be able to help build any fintech app has many considerations. But the effort we made to perfect it is already starting to pay off.

The framework meets the original expectations of providing flexible solutions to common fintech app development challenges, taking into consideration the specific needs of the market such as support for older browsers and more. As a result, our developers were immediately tasked with developing new fintech apps based on the framework.

Currently, we’re simultaneously working on four applications based on the framework. Instead of developing the same features over and over again, we are able to focus on the business logic only, which also helps us focus even better on what the application is supposed to do and accomplish – the fewer distractions from it, the better.

Besides, there are also many strict developer skills we polished which are sure to help with future projects:

• Experience in building highly complex and scalable apps built in a way that allows to easily switch implementations (“program to interfaces, not implementations!”).
• Deep knowledge of Ext.js and the many ways it can be used to quickly create efficient user interfaces.
• Knowledge of building custom database and security solutions, which employ technologies such as WebSockets or CQRS.

It sure was an enlightening experience! As we build more and more fintech apps with it and apply these use cases to the main framework, it’s sure to become even more powerful and flexible, minimizing the time it takes to develop and deploy new applications.