The FOLIO platform consists of both server-side and client-side components, and will grow to include library services that run on the platform as modules. Various repositories in the folio-org GitHub organization host the core project code. Third-party modules may be hosted elsewhere.

The Source-code map enables navigation to details of modules.

A good starting point for understanding the FOLIO code is Okapi – specifically the Okapi Guide and Reference, which introduces the concepts and architecture of the FOLIO platform, and includes installation instructions and examples. Okapi is the central hub for applications running on the FOLIO platform and enable access to other modules in the architecture.

The FOLIO system is made up of the code in several GitHub repositories. Each repository contains the code for a single well-defined element of the system. These repositories fall into three categories:

• server-side elements that provide services and the infrastructure that they run on;
• client-side elements that provide a framework for using those services from a Web browser;
• and some that fall into neither of these categories.

FOLIO follows the release early, release often philosophy.

We want your feedback in the form of pull requests and filed issues (the README of each module has a link to its issue tracker) and general discussion via the collaboration tools.

Server-side

The key server-side element is Okapi itself: the FOLIO middleware component that acts as a gateway for access to all modules, handling redundancy, sessions, etc.

Individual back-end modules are provided in their separate repositories, each named following the “mod-name” convention. Each back-end module has its own documentation.

It is highly recommended that modules be developed using an API-first methodology. An API declaration is first created around which code is then implemented. The recommended format for API declaration is the OpenAPI Specification OAS. (Previously RAML was used, but its use is now deprecated.)

Refer to the introduction of the various bases that facilitate development of back-end modules.

Refer to the map for all Backend infrastructure repos and Backend mod repos and Backend edge repos and Shared RAML repos.

Client-side

Since Okapi represents all the FOLIO functionality as well-behaved web services, UI code can, of course, be written using any toolkit. However, we will provide Stripes, a toolkit optimized for accessing Okapi-based services and wrapping UI functionality into convenient modules. We envisage that most FOLIO UI work will be done in the context of Stripes.

The stripes documentation is the starting point.

Individual front-end UI modules are provided in their separate repositories, each named following the “ui-name” convention. Each front-end module has its own documentation.

Refer to the map for all Stripes repos and Frontend ui repos and Frontend ui plugin repos.

Platforms

Stripes Platforms are integrated sets of modules based on the dependencies of that platform’s front-end modules.

Refer to the map for all Stripes platform repos.

Other projects

Various other FOLIO projects that do not fit the above classifications are listed separately.

Refer to the map for the various Other repos.