Architecture

A modular, modern, built-for-cloud architecture

A key architectural piece of FOLIO is the Okapi API gateway. The specification of the core Okapi web services, in its current form, is captured in RAML (RESTful API Modeling Language). All API requests are routed through Okapi to backend modules.

Modules in the Okapi ecosystem are defined in terms of their behavior (or, in other words, interface contract) rather than their contents, meaning there is no exact definition of a module as a package or an archive, e.g. with the underlying file structure standardized. Those details are left to the particular module implementation (Okapi server-side modules can utilize any technology stack). Sometimes modules implement persistent storage, but this is not a requirement of a module.

The user interface is built using the Stripes framework. We want UI modules to form an integrated and consistent whole, and using Stripes as a client-side only tool — it runs entirely in the user’s browser and consumes FOLIO services directly, we are able to achieve the consistency desired. While important, we also know this won’t be the only interface to the web services that comprise FOLIO. External Systems will also act as clients to our FOLIO services, and may target Okapi directly, or may target an “edge-module” which may perform a task like a protocol conversion (e.g. Z39.50 to HTTPS).

Modules’ work can depend on activity happening elsewhere in the system. In these cases a message queue is used for modules to publish or subscribe to message streams to coordinate this work. This approach allows FOLIO to maintain its modularity.