You are currently viewing Building a Trading Platform – Part 2: Technology Stack
choosing tech stack for trading platform

Building a Trading Platform – Part 2: Technology Stack

After outlining the general idea of our platform in the previous article, let us explore which technologies we can use to get the job done. Finding the right solutions requires an understanding of what we want to achieve. Which resources do we have available? What compromises we can accept to build a first MVP?

For the selection of the right technologies, a flat learning curve and a low upfront investment are crucial decision criteria. Our business requirements are fairly complex. A strict focus on the business logic, easy testing, and a lean deployment process, with little need for continuous maintenance of the codebase, are critical factors. We are therefore looking for one or more frameworks that allow a fast set-up of our environment, so we can focus on implementing our idea.

The core

At the heart of our platform stands the creation and modification of objects, the processing of transactions, and the reporting and analysis of those transactions. We want a database application that allows data processing on one hand and data analysis, monitoring, and maintenance. Virtually all relational DBMS can fulfill that task, which is why we will start with a simple MySQL instance for our data storage, sparing us the cost of heavier systems like Oracle DB.

We will conduct the visual data modelling itself via yEd, a JAVA based software for the design of technical graphs with a proprietary software license, that allows limited use free of charge. It supports the major modelling diagrams like BPMN and UML and comes with less complexity than heavier systems, like MS Visio.

For the programming of the business logic itself, we will use Spring Boot for Java. Spring Boot comes with powerful modules for implementing JWT based Web Security, Data Access via JPA, Testing and RESTful Web Services of which we will make use in this project. The modules can be added, removed, and configured as Maven dependencies.

To conveniently manage our Maven project in our IDE, we are choosing Intellij, which offers numerous extensions for further integrations, thanks to its widespread use and active community.

One of those integrations is GitHub, a version control solution, that allows us not only to track changes and enable collaborative development once desired, but it also supports further integration of third party systems for code analysis and even continuous delivery with CI/CD via hosting providers like HEROKU by Salesforce or Microsoft Azure.

The Front-End

Angular Logo
Vuejs logo

We now have a working setup for the development of the backend. Since we designed our backend as an API we now have plenty of options for the design of our front-end. The 3 most popular choices currently in use are Angular, React.js and Vue.js. Out of those, Vue.js is considered the easiest to learn and get started. However, while the framework is lean and fast, its missing type safety creates challenges during the creation of larger web applications. For this project, we will therefore opt for Angular as an established framework with wide usage across the financial industry and a vast community.

Visualising the Landscape

We have now determined a basic setup for our application landscape. To summarize, the following graph will show how the components interact with each other.

Deploying the application

As mentioned above, using GitHub as a source code repository enables a seamless integration with hosting platforms such as Google Cloud, Microsoft Azure or Heroku, besides others. Amongst the major hosting providers for complex web applications, Heroku stands out through a highly user-friendly GUI, a transparent billing process and great user support with detailed insights into the Heroku Architecture.

The hosting platform supports Source-to-Image compilations of web projects, wherein a server polls updates on the source code repository to detect new commits. Once the server detects a commit, it triggers a new application build to create a deployment image, called a “slug”. The Dyno Manager orchestrates the Linux Containers, called “Dynos” for the applications on the tenants of a geographical region within the Heroku infrastructure.

Transforming the visualisation of our architecture into a more infrastructure focused perspective, we get the following landscape:

Where do we go from here?

In this article, we mapped out a strategy to build a front-end and a back-end for our trading platform. Looking at Heroku, we examined a solution that offers a cheap and easy to navigate way of hosting our application with a comprehensive delivery process.

Besides the approach outlined here, there are many technologies you can use to build an application with similar requirements, and most of them will get you to where you need to be. However, the strategy outlines above provides a solid foundation that enables you to quickly create a fully functional MVP. This is a lean and efficient delivery process and powerful scalability opportunity by following popular and widely used containerisation strategies.

In the next article, we will explore how to create a Spring Boot “hello world”-application and setup version control with an integration into the Eclipse IDE.

I hope you enjoyed reading the article!

What do you think about the chosen technology stack?

Would you choose any different solutions and why?

Please leave your feedback in the comments below!

Leave a Reply