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. Some sample modules are located in folio-sample-modules.

Several repositories in the folio-org GitHub organization host the core project code. Third-party modules may be hosted elsewhere.

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 enables 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 a few that fall into neither of these categories.

PLEASE NOTE that this is a technology preview following the release early, release often philosophy. We want your feedback in the form of pull requests and filed issues 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 modules are provided in their own repositories, each named mod-name (note that these are mostly at the proof-of-concept stage). Each module has its own documentation.

Some of these modules are built from specifications in RAML, the RESTful API Modeling Language: this process is facilitated by the code in the raml-module-builder repository.

  • okapi – Okapi API Gateway proxy/discovery/deployment service.

  • raml – Repository of RAML files, including JSON Schemas, traits and resource types centralized for re-usability. The API reference documentation is also generated. This repository is the master location for the traits and resource types, while each module is the master for its own schemas, examples, and actual RAML files. It is included in other repositories via a git sub-module, usually called raml-util.

  • raml-module-builder – Framework facilitating easy module creation based on RAML files.

  • mod-authtoken – Filtering requests based on JWT tokens.

  • mod-login – Handles username/password login.

  • mod-permissions – Handles permissions and permissions/user associations.

  • mod-users – Provides user management.

  • mod-users-bl – Business logic “join” module to provide simple access to all user-centric data.

  • mod-inventory – Provides basic physical item inventory management.

  • mod-inventory-storage – Persistent storage to complement the inventory module.

  • mod-circulation – Circulation capabilities, including loan items from the inventory.

  • mod-circulation-storage – Persistent storage to complement the circulation module.

  • mod-configuration – Demo configuration module based on the raml-module-builder and a set of RAML and JSON Schemas backed by a PostgreSQL asynchronous implementation.

  • mod-notes – Notes on all types of objects.

  • mod-acquisitions – Demo acquisitions module, based on the raml-module-builder framework, exposing acquisition APIs and objects against MongoDB.

  • mod-acquisitions-postgres – A second demo acquisitions module, also based on the raml-module-builder framework and exposing acquisition APIs and objects, but implemented with an asynchronous Postgres client.

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-core documentation roadmap is the starting point. Each module has its own documentation.

Note that Stripes is still in the design phase, so although code exists and can be run, the APIs are likely to change.

  • stripes-core – The UI framework. Includes extensive documentation.

  • stripes-sample-platform – Configuration for a sample platform and to run a local Stripes UI development server.

  • stripes-components – A component library for Stripes. Includes documentation for each library, and guides to assist their development.

  • stripes-connect – Manages the connection of UI components to back-end modules.

  • stripes-form – A redux-form wrapper for Stripes.

  • stripes-redux – A collection of utility functions and middleware for redux and redux-observable.

  • stripes-logger – Simple category-based logging for Stripes.

  • ui-users – Stripes UI module: administrating users.

  • ui-items – Stripes UI module: administrating bibliographic items.

  • ui-requests – Stripes UI module: making requests on items.

  • ui-checkin – Stripes UI module: checking in items with simulated scans.

  • ui-checkout – Stripes UI module: checking out items with simulated scans.

  • ui-organization – Stripes UI module: managing organization settings.

  • ui-developer – Stripes UI module: developer facilities, e.g. managing local developer settings.

  • ui-plugin-find-user – Stripes UI plugin: User-finder.

  • stripes-loader – Module loader for Webpack, to enable pluggable Redux applications. This module is responsible for pulling the required UI modules into a given Stripes UI.

  • okapi-stripes – Server-side module for generating UIs based on Stripes.

  • stripes-demo-platform – Stripes platform for building the demo site.

  • ui-okapi-console – Stripes UI module: console for administrating Okapi.

  • stripes-experiments – Testing ground for prototype modules that may form part of Stripes.

Other projects

  • folio-sample-modules – Various sample modules, illustrating ways to structure a module for use with Okapi (e.g. hello-vertx and simple-vertx and simple-perl).

  • folio-ansible – Sample Ansible playbook and roles for FOLIO (and Vagrant). Get a FOLIO installation up and running quickly. Read the docs there, and follow to build the boxes. The current built boxes are also available to download from Vagrant Cloud.

  • cql2pgjson-java – CQL (Contextual Query Language) to PostgreSQL JSON converter in Java.

  • ui-testing – Regression tests for FOLIO UI.

  • folio-org.github.io – The source for this dev.folio.org website.