WOLFcon 2024

From the earliest design of the FOLIO platform, it was constructed to be modular. The heart of every FOLIO system is a well-defined platform consisting of Okapi and some core modules to handle authentication and related concerns. This provides a surface onto which any module can be deployed — depending on some interfaces and providing others.

This approach provides multiple concrete benefits. First, it enforces a partitioning of concerns, with contract-defined API-based communication between modules. Second, it allows new functionality to be added as a module without requiring changes elsewhere in the system. Third, it allows multiple modules to provide alternative implementations of the same interface, with consumers of that interface neither knowing nor caring what module implements it.

FOLIO’s Reporting app consists of a UI module (ui-ldp) and a back-end module (mod-ldp) which communicates on the UI module’s behalf with the MetaDB datastore. mod-ldp is old code, written by a third party using tools alien to its maintainers, insecure in places, and badly in need of updates. We therefore decided to re-implement mod-ldp’s interface by a new module written in Go (mod-reporting). The new module is plug-compatible with the old, providing the same version of the same interface, and has been deployed in place of its predecessor with no problems whatsoever. The existing UI module has not been changed to accommodate it, and continues to work exactly as before.

Our experience provides an example of how such code upgrades can be performed, and provides a pathway for piecewise refreshment of parts of FOLIO as they age out. A similar technical approach can also enable the substitution of different implementations of an API, for example implementing a plug-compatible mod-fqm-manager replacement that runs queries against MetaDB.