The two backend platforms for FOLIO, Okapi, the original platform, and Eureka, the future platform, have distinct architectures.
The Okapi Platform
Okapi performs a variety of tasks in the classic FOLIO architecture, responsible for:
Gateway - Acts as the main point of entry for API requests.
Module Management - Manages modules, stores module descriptors, and verifies necessary interfaces and dependencies.
Stores Discovery Information - Stores information about module deployment locations.
Tenant Management - Maintains a database of tenants and their enabled modules.
Module Installation and Uninstallation - Handles enabling or disabling modules for specific tenants.
Module-to-Module (M2M) Proxy - Facilitates communication between modules.
Authorization Filter - Examines token permissions and verifies response.
Timer API - Schedules jobs using the timer API in module descriptors.
...
The Eureka Platform
Eureka introduces a more distributed architecture with a clearer separation of components:
API Gateway - Uses Kong as an API gateway without authorization responsibilities.
Identity and Access Management - Manages all authentication and authorization processes with Keycloak.
Sidecars - Supports module-to-module communication by using sidecars, an architectural pattern.
Applications Manager - Manages discovery data and application descriptors.
Tenant Manager - Uses an API to manage tenants.
Tenant Entitlement Manager - Manages installing and uninstalling applications via API.
Key Differences
Architecture - Okapi centralizes many functions, while Eureka distributes them across multiple components.
Authorization - In Okapi, it's centralized; in Eureka, it's handled by module-specific sidecars.
...
Both platforms support the FOLIO ecosystem, with Eureka representing an evolution in architecture to address some limitations of the original Okapi design.