Skip FOLIO Project Navigation

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-configuration – Configuration module based on the raml-module-builder and a set of RAML and JSON Schemas backed by a PostgreSQL asynchronous implementation.

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

  • mod-login – Handles username/password login.

  • mod-login-saml – Handles SAML login.

  • mod-password-validator – Performs password validation and stores validation rules for specified tenant.

  • 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-user-import – Importing new or already existing users into FOLIO.

  • 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-calendar – Provide calendar functionality.

  • mod-feesfines – Provide central management for fees and fines.

  • mod-datasets – Wrapper for running a Glint server as an Okapi module.

  • mod-graphql – Executing GraphQL queries.

  • mod-kb-ebsco – Broker communication with the EBSCO knowledge base.

  • mod-kb-ebsco-java – Broker communication with the EBSCO knowledge base.

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

  • mod-notify – Notifications to the users.

  • mod-sender – Intermediary for sending prepared messages through appropriate delivery channels.

  • mod-email – Provides functionality for sending notifications.

  • mod-event-config – Provides functionality for the notification events.

  • mod-codex-mux – Codex Multiplexer.

  • mod-codex-mock – Codex mock module - for testing and development.

  • mod-codex-ekb – Codex wrapper for the EBSCO knowledge base.

  • mod-codex-inventory – Codex wrapper for local inventory.

  • mod-marccat – Metadata management and cataloging (MARCcat).

  • acq-models – Shared repository for the models of the various acquisition modules.

  • mod-finance – Finance business logic.

  • mod-finance-storage – Persistent storage of finance-related data (i.e. funds, ledgers, transactions, etc.).

  • mod-orders – Orders business logic.

  • mod-orders-storage – Persistent storage of order data.

  • mod-receiving – Business logic for receiving and checking-in materials that have been ordered.

  • mod-patron – Allow 3rd party discovery services to perform FOLIO patron actions via the discovery service’s UI.

  • mod-rtac – Real Time Availability Check. Enable third party discovery services to check for FOLIO inventory availability.

  • mod-tags – Central list of tags that can be assigned to various objects.

  • mod-template-engine – Stores templates and generates files by using them.

  • mod-data-import – Data import.

  • mod-source-record-storage – Persistent source record storage. Complements the data import module.

  • mod-source-record-manager – Source record manager.

  • data-import-raml-storage – Shared repository for the schemas of various data-import modules.

  • mod-vendors – Persistent storage of vendor data.

  • mod-agreements – Electronic resource management (ERM)

  • mod-erm-usage – Store ERM usage statistics and access data to these statistics.

  • mod-erm-usage-harvester – Harvest ERM usage statistics.

  • mod-licenses – Upload, manage and analyze licenses.

  • mod-gobi – Allows GOBI® (Global Online Bibliographic Information) initiated orders to be fulfilled by FOLIO.

  • mod-oai-pmh – Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH).

  • mod-workflow – Workflow proof-of-concept. With related modules: mod-camunda, spring-module-core, mod-spring-sample.

  • mod-audit – Manage audit data.

  • mod-audit-filter – Implements Okapi PRE and POST filters to capture audit data.

  • mod-aes – Provide asynchronous event service (AES).

  • mod-rmb-template – A Maven archetype to commence a new RMB-based module.

  • mod-pg-embed – Helper module to start embedded Postgres. Helper for developers that starts the “embedded” postgres server and sets up the environment so that other modules can locate the database.

  • mod-data-loader – RMB-based module used to load test data. Currently supports loading binary MARC records into the mod-inventory-storage instance table.

  • inventory-sample-data – Provides scripts for data preparation and deployment, e.g. MARC.

  • edge-common – Common/Shared library for Edge APIs.

  • edge-oai-pmh – Edge API for Metadata Harvesting.

  • edge-orders – Edge API to interface with FOLIO for 3rd party ordering services and FOLIO. Initially GOBI.

  • edge-patron – Edge API to interface with FOLIO for 3rd party discovery services to allow patrons to perform self-service actions.

  • edge-resolver – Edge API to bridge the gap between external reporting and analytics systems and FOLIO by allowing these systems to resolve FOLIO UUIDs, such as a FOLIO user id, thereby acquiring a richer set of data.

  • edge-rtac – Edge API for RTAC (Real Time Availability Check). To interface with FOLIO for 3rd party discovery services to determine holdings availability.

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. 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 – The Stripes Framework. UI framework for building front-end FOLIO modules. Includes extensive documentation.

  • stripes-core – The core of the Stripes/UI framework.

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

  • stripes-smart-components – A suite of smart components. Each communicates with an Okapi web-service in order to provide the facilities that it renders.

  • stripes-util – A library of utility functions to support Stripes modules.

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

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

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

  • stripes-cli – Command-line interface for creating, building, and testing Stripes UI modules.

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

  • ui-inventory – Stripes UI module: administrating locally created instances, holdings records and items.

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

  • ui-calendar – Stripes UI module: institutional calendar functions.

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

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

  • ui-circulation – Stripes UI module: Circulation.

  • ui-datasets – Stripes UI module: FOLIO Datasets based on Glint.

  • ui-data-import – Stripes UI module: Managing batch data loader.

  • ui-marccat – Stripes UI module: searching, sorting, filtering, viewing, editing and creating BIB record.

  • ui-orders – Stripes UI module: Orders.

  • ui-receiving – Stripes UI module: Receiving.

  • ui-eholdings – Stripes UI module: E-holdings.

  • ui-agreements – Stripes UI module: Electronic resource management (ERM).

  • ui-erm-usage – Stripes UI module: Managing ERM usage statistics.

  • ui-licenses – Stripes UI module: Upload, manage and analyze licenses.

  • ui-search – Stripes UI module: searching, sorting, filtering and viewing records from the FOLIO Codex, an aggregation of bibliographic metadata from multiple sources.

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

  • ui-myprofile – Stripes UI module: managing user profile settings.

  • ui-tags – Stripes UI module: managing tag settings.

  • ui-finance – Stripes UI module: management of ledgers, funds, and budgets.

  • ui-servicepoints – Stripes UI module: Service Points handler.

  • ui-vendors – Stripes UI module: Vendors.

  • ui-audit – Stripes UI module: Viewing audit trails.

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

  • ui-plugin-find-instance – Stripes UI plugin: Instance finder.

  • ui-plugin-find-vendor – Stripes UI plugin: Vendor finder.

  • ui-trivial – Stripes UI module: example application.

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

  • eslint-config-stripes – The shared eslint configuration for stripes applications and extensions.

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

  • platform-complete – Stripes platform: Complete.

  • platform-core – Stripes platform: Core.

  • platform-erm – Stripes platform: ERM.

  • folio-testing-platform – Stripes platform: Testing.

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

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

  • stripes-testing – Toolkit for running tests against Stripes UI modules and platforms.

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

Other projects