Components - Structure and interactions
The FA Platform is a collection of applications and services, combined with a persistence layer, that is made available to customers as a SaaS service. It is most commonly accessed through a browser: users of the FA Platform log in and interact with the platform through its web UI.
Although the platform consists of a large number of applications and services, that complexity is hidden from users of the platform: they simply access various features and sections of the FA Platform without needing to know about the underlying architecture.
This section describes how users and external systems interact with the FA Platform, and how various parts of the FA Platform interact with each other, through synchronous request-response and asynchronous messaging-based models.
 |
Components
The FA Platform contains various applications, services, and persistence technologies.
Applications provide user interfaces to features of the platform. They are rendered in the user’s browser.
Services provide access data through API endpoints, and they perform various data processing activities. Services are not application-specific, but instead focused on specific functionality. Some services may be accessed from outside the platform via APIs. Some services are restricted to access by other services. A third category of services independently performs data processing tasks in response to events in the platform.
Persistence for data is provided through various technologies, including SQL and NoSQL databases.
Interactions
Browser-based access
The primary way to access the FA Platform is through a browser. When the user enters the URL of their FA Platform instance, they get redirected to a centralized login screen. After successfully entering their credentials (username, password, two-factor authentication and/or integration with some external identity provider), the user is redirected to the application itself.
The user’s requests are routed to a specific application instance by a proxy, and they are authenticated based on the OAuth 2.0 protocol using JWT. Thanks to our centralized authentication model, users of the FA Platform can seamlessly switch between applications without having to authenticate themselves multiple times.
Our preferred way of developing the FA Platform is to separate front-end applications from back-end services. With this approach, the user’s data is provided to the user of the front-end application through API calls to a back-end service. GraphQL is our preferred API technology for this kind of communication.
Our backend services communicate with the persistence layer through a network connection using various protocols and formats (depending on the persistence technology in question).
Access to external systems
The FA Platform provides a broad set of APIs that external systems may use to interact with the FA Platform. Systems access the FA Platform in a similar way to browsers: requests are routed by a proxy and authenticated with OAuth 2.0 and JWT. The main difference is, that API requests from external systems access our API endpoints directly, and bypass the browser / front-end application entirely. Another difference is that API requests from external systems are always stateless, whereas certain older parts of the FA Platform are currently session-based.
Service-to-service requests
Various features of the FA Platform require our services to interact with each other. This is done in several ways:
Through the persistence layer (service A writes data, service B reads it)
Through messaging (publisher-subscriber model or point-to-point)
Direct service-to-service API call (service A calls and endpoint of service B, which responds)
Service-to-external-system requests
The FA Platform supports integrations to various external systems. Fetching end-of-day pricing information is an example of a common integration between the FA Platform and an external system. Such integrations require our services to send requests to external systems with various different protocols (such as HTTP/HTTPS, FTP/SFTP, SMTP, TCP, SMTP), and transferring data in various different technical formats (JSON, XML, CSV, and so on) and content formats (proprietary formats, and standard formats such as PAIN.001, MT540, setr.010.001.04).