Skip to main content

Backend

Components​

Java 21 Runtime​

The backend services are built using Java 21, with support for any Java distribution (e.g., OpenJDK, Azul). All microservices are built with Spring Boot 3.x and Spring Cloud for microservice orchestration, communication, and scaling.

  • Java Version: 21
  • Framework: Spring Boot 3.x, Spring Cloud 2023
  • Deployment: Each service is containerized using Docker and deployed in a Kubernetes environment.

API Gateway​

The tSM platform uses a standard API Gateway implemented as a Spring Boot application. The API Gateway serves as a reverse proxy, routing client requests to the appropriate backend services. It handles security concerns, load balancing, and rate limiting while providing a unified entry point for all client interactions.

  • Technology: Spring Boot 3.x
  • Purpose: Reverse proxy for backend microservices, managing security, load balancing, and rate limiting.

Other Service Types​

While most backend services are implemented using Java and Spring Boot, the platform allows for services written in other languages and frameworks. For example, a microservice could be developed using Python for specific tasks that may require different libraries or environments (e.g., data processing, AI/ML tasks).

  • Example: A Python-based microservice for data processing or machine learning tasks could be deployed alongside Java-based services.
  • Deployment: Python services can also be containerized using Docker and orchestrated within the Kubernetes cluster, ensuring consistency across the platform.

Configuration Management​

All services in the tSM platform are configured using Spring Boot YML configuration files, which provide a standardized way to define application properties. These configurations can be externalized and customized depending on the deployment environment. The platform supports configuration through various mechanisms:

  1. YML/Properties Files: The default configuration for each service is defined using standard Spring Boot application.yml or application.properties files.

  2. Environment Variables: Configuration properties can be overridden by environment variables, allowing dynamic configuration adjustments at runtime, especially in containerized environments.

  3. Kubernetes ConfigMaps and Secrets: In Kubernetes environments, configurations can be externalized using ConfigMaps and Secrets, which are mounted into the container or injected as environment variables.

  4. Spring Cloud Config Server: For dynamic configuration management across multiple environments (dev, staging, production), the tSM platform can use Spring Cloud Config Server. This allows centralized management of configuration files stored in version control (e.g., Git), enabling externalized and consistent configuration across microservices.

  • Configuration Sources:

    • Local YML/Properties Files
    • Environment Variables
    • Kubernetes ConfigMaps/Secrets
    • Spring Cloud Config Server

  • Flexibility: These configuration options provide flexibility for the platform to be customized and adapted to any environment, whether it's an on-premise server, a containerized solution, or a cloud-native infrastructure.