At the moment of writing the landscape is a bit foggy. We do not know everything and this document will be updated once we know more.
Getting started
This document will help you to get a better understanding of the application landscape maintained by development.
Goals
The development department of True is an service providing department within the company. Most of our applications are automating time consuming or error prune processes. We are servicing not exclusively the following departments.
- Support a.k.a Tech
-
Sales
- Customer Success Management
- New Business
- Finance
Beside that we are also building a customer portal, used by True's customers. Providing a ticket tool and some self service tools.
Landscape
We have two main purpose front-end applications, known as true-care and new admin. Both are living in the same gitlab repo and are written in a so called mono-repo so they can share components and functionality. Both applications are using the various micro-services to perform actions and collect data to display.
Security
The authentication and authorization on true-care and new_admin are done via an authentication provider called accounts. This application is used to manage user sessions and authentication via various identity providers. To do this a combination of OAuth2 and OpenID Connect is used. With an extra feature on top of this to handle the user permissions per organisation. More details about accounts can be found in the accounts section of this documentation website.
Architecture
This section is not complete yet. We working towards a new architecture. This section will be updated once we are making progres on the new architecture.
We are building a https://awesome-architecture.com/modular-monolith/.
Legacy
Architecture
We are using a microservice architecture. Most microservices are providing a REST API. And some communication is done via RabbitMQ. We have 2 types of microservices right now:
- Public
- These microservice are connected to new_admin and true-care. Their API is reachable from the public internet. When a user has application permissions to communicate with the API, one could use a self written client to do the communication. Not all microservice that are public facing are officially supported for custom clients.
- Internal
- A small set of microservices running in a separate deployment environment. That is not reachable from the internet. Some of them do have an API, others are just consuming RabbitMQ messages.
Legacy
As every self-respecting company we do have legacy applications. The former members of the development team started an effort to refactor an complex monolith into multiple microservices. Those microservices are replacing the old admin application. Unfortunately just partially right now. And some major processes are still handled by this old admin application.
There is no complete list of the functionality used in the old admin. We do have a project in progess to get this information. https://app.asana.com/0/1203003894982471/board
We do not have full sight on the landscape. It could be that we have more legacy applications that we are not aware of right now.
Test accounts
In new_admin and true-care it is possible to test with your own account, but if you want to test with a customer account you can use the usnew0009 account. When testing tickets locally you can use the usnew0013 account.