You are currently viewing Building a Trading Platform – Part 11: Designing an Angular Front-End

Building a Trading Platform – Part 11: Designing an Angular Front-End

Our JAVA Spring boot back-end now has enough basic functionality to begin the design of a front-end. As described in Part 2 of this article series, our framework of choice is Angular, due to its maturity and wide industry usage. Like its competitors, it provides most required functionality out of the box, so we will not deep dive into each part. If you decide to learn it, however, the Angular documentation is outstandingly well written. I also highly recommend reading it beyond just the tutorial for introduction, even if you have prior experience with other frameworks

Component Libraries: PrimeNg vs. Material

While Angular delivers a lot of JavaScript functionality, it does not help us with the actual design of the visual side of our application. Luckily, most developers encounter the same challenge, which led to the development of component libraries. Component libraries contain reusable HTML components, with a consistent styling and some given functionality, like a filtering option for tables.

Much like with Angular vs. React or other big libraries, picking a component library largely depends on personal preferences, since most libraries provide similar features. In fact, different libraries can even be mixed, at least in theory. In reality, however, combining different component libraries leads to risks that can cause issues down the road. For example, their position on the Z-axis might not be aligned, leading to components disappearing. Fixing these issues takes a lot of time and reduces maintainability.

After careful consideration and some implementation effort, the choice as our main library is in favour of Angular Material. The library was developed and maintained by Google, a reliable partner, to ensure the longevity and stability of the library.

Angular Application Structure

Now that we know which framework and library to use for the front-end, it is time to determine what the application should show.

There are 2 main sections of the application, which we can differentiate:

For visitors of the website, we would like to display some public information, like an explanation, what this site is about. It should also serve as a portfolio, demonstrating how we built the application. Last, there are legal disclaimers required for most websites, so we must implement those too.

Of course, the core of our application is the trading platform. The trading platform should show a user’s trading history and ultimately allow him to connect to a broker and execute trades. Of course, for these features, we need a protected area with a login.

Once the user logs in, we want to keep the user interface lean and scalable. To ensure this, it will follow the structure we designed for the backend. This means we will need a menu with a section each for “Master Data” like a person’s contact data, “Transaction Data” like payments and stock trades, as well as “Control Data” like settings for the application. To monitor the data in our system, we will also need a section to manage our existing data.

Luckily, as we described in Part 7 of this series, we introduced the concepts of orders, which are used in many major business applications. How does that help us now?

Orders can either create and modify master data or generate transaction data. We can leverage this here, because it means that we can reuse the same user interface for either type of data. That keeps the effort for development and code maintenance low.

An application only gets interesting if we can set data into relations. Much like you may have a favourite song on Spotify or bookmarks in your browser, in our application you may also want to manage some favourites, like your favourite Tesla Call options or the broker account you want to use for trading.

Let us see how this may look like:

screenshot of angular user interface

While the layout is plain, you can observe that it follows a powerful architecture that allows the management of a vast variety of data and scenarios, without the necessity of complex implementation efforts every time a new requirement comes in. Instead, you can just generate a new type of object or transaction and define the extensions for each of them. For example, if you were to create a new object of type “Financial Instrument”, you may add a key called “ISIN” and a class called “Risk Category” or virtually any other type of data that helps describe that entity.

This overview shall conclude our exploration of the design of the frontend. Of course, there are many questions left open, as for how the implementation works in particular. The answers to these questions will be answered in the coming articles.

Leave a Reply