Skip to end of metadata
Go to start of metadata

18-July-2018

Overview

This document is provided to help the community with terminology and concepts that can help define the different aspects of FOLIO and the software systems that are part of it. We expect that future projects will be modeled after FOLIO and share FOLIO's Platform, but will have separate domain "Base" modules and "Extended" apps.

FOLIO Platform

The FOLIO project is the first initiative to be developed under the Open Library Foundation’s sponsorship. As such, there are fundamental building blocks that have been created that enable FOLIO and many other projects to grow and flourish. This foundational platform is problem-domain agnostic: it will enable software solutions that solve many problems in the library space. In fact it would enable solutions even outside the world of libraries.

This platform establishes a basic software architecture and delivers fundamental services that any application set would require. These services are general, utilitarian, and domain agnostic. Specifically, they do not assume, enable or support specific workflows within any domain. They are building blocks. In some ways the analogy of an Operating system is appropriate for this platform. In and of itself the platform pieces are of little functional value. The domain-specific application is required before value is realized for users and communities.

The platform can be described in three general pieces:

Runtime components and frameworks

FOLIO Platform back-end is based on a microservices architecture that leverages an API Gateway to insulate module implementers from needing to understand operational details of other services in the platform, in addition to providing a robust system for control, load balancing, reporting, tenant-separation, etc. This API Gateway is called Okapi and the module development framework is called RAML Module Builder (RMB). RMB is addressed to Java developers and provides facilities for building JSON APIs and seamlessly storing JSON objects in a Postgres database.

A second essential part of FOLIO is the front-end development toolkit and a set of reusable user interface components. The toolkit provided by FOLIO is called Stripes and it allows teams to build user interface modules (often called apps) that nest within the FOLIO single-page web application (SPA). UI modules are made up of Stripes components, based on React, some of which are connected to back-end services provided by Okapi.

Fundamental application building blocks

Every system will require users, permissions, authentication and secure inter-communication mechanisms. Likewise, every system needs a configuration mechanism. The platform provides these utilities via:

  • mod-users

  • mod-permissions

  • mod-authtoken

  • mod-configuration

Software Development Lifecycle Practices and Utilities

FOLIO Platform establishes certain development lifecycle practices such as the CI/CD pipeline, the automated test suites, standards around tooling, coverage expectations, deployment patterns and established environments that allow development teams to easily integrate new code and functionality. Those practices are provided in form of infrastructure management code (folio-infrastructure, folio-ansible, folio-install) and documentation.

Likewise there are command line tools that are designed to allow system operators and developers to leverage the platform capabilities in a quick, convenient and automatable fashion. Those tools are the Okapi-CLI and Stripes-CLI.

FOLIO LSP Base

To provide library-specific functionality on the level of contemporary Library Services Platform, FOLIO project is actively developing a set of backend modules and staff user applications that will eventually form a consistent solution to everyday tasks of running a library. Those modules are designed to run on the FOLIO Platform and are built both by the FOLIO Core Team and External Teams that closely follow FOLIO style and design guidelines. Those modules are fully replaceable and selectable, however, due to interdepencies between them it may be required to select full subsets of those apps to provide required functionality. We use the term FOLIO LSP Base to denote them. LSP stands for Library Services Platform.

FOLIO LSP Base includes, but is not limited to the following:

User Management, Inventory and Circulation suite of modules:

    • mod-circulation

    • mod-inventory

    • ui-checkin/checkout

    • ui-users

    • ui-inventory

    • ui-calendar

Acquisitions suite of modules: (non-exhaustive):

    • ui-orders

    • ui-vendors

ERM’s suite of modules

FOLIO LSP Extended Apps

FOLIO LSP Extended Apps are library-domain specific modules and apps that are provided by FOLIO partners. The key characteristic of “Extended Apps” is that their use is ancillary and optional in terms of running a library. Clearly they can be useful, but they are not essential. It’s generally encouraged that all FOLIO apps follow the common set of usability and look/feel guidelines, although this is not a requirement for extended apps. Note that there are no functional dependencies between FOLIO LSP Base apps and Extended Apps, as they operate side-by-side. FOLIO LSP Extended Apps are fully replaceable and selectable.

Examples of potential FOLIO LSP Extended Apps:

  • Collection analysis tools
  • Reporting tools for tracking physical conservation and digital preservation activities
  • Integration with learning management systems
  • Curatorial value assessment records and associated documentation
  • Records of movement of items within an organization (typically used for museum collections)

Implications of Platform vs LSP Base vs Extended Apps

The distinction between these categories implies a certain level of “centralness” and with that comes added governance. The table below begins to outline the current thinking. Note that the table below is meant to convey directional intent. We currently do not have policies or guidelines that dictate this governance.



Platform

LSP Base

Extended

Development team

Core

PC-coordinated

open

Technology stack

TC-approved

TC-approved

Team specific

Adherence to DoD

Strict

Strict

Encouraged

Manage Pull Request

Core

Module-moderator

open

  • No labels