Overview

There's interest in determining the minimal set of modules to run a bare-bones FOLIO instance.  The expectation is that we'll likely find modules which are currently required, but shouldn't be (e.g. inventory/inventory-storage).  Ideally we can address these situations and define a "platform-minimal" that makes sense, and would allow the FOLIO platform to be used for non-LSP application development.

Motivation

The motivation for this work is twofold:

• Both the Technical Council and various interest groups (TL, SysOps SIG, etc) discussed the complexity stemming from the fact that FOLIO consists of large and an ever-growing number of distributed but highly inter-connected modules. This complexity creates operational, architectural and scalability challenge for developing, shipping and running FOLIO. It's been discussed that un undertaking to analyse and potential limit or reorganize dependencies in FOLIO should be started in FOLIO but no specific details or next steps have been agreed on. The activity to define "platform-minimal' is seen by some members of the TL as an activity that could kick-start this process by analysing and reorganising dependencies for the so-callled "core" set of modules
• The team behind Sinopia (Entity editor to become part of FOLIO)expressed a need for the minimal version of the FOLIO platform to allow their existing users to continue running Sinopia during the transition to the FOLIO platform.

JIRA

• FOLIO-3253 - Getting issue details... STATUS

Actions

• Marc Johnson to touch base with steve.osguthorpe who might have investigated this not too long ago
• Jakub Skoczen to add some context to this page providing insight into the motivation behind doing this... Started with Sinopia, but there are other aspects to this.
• Craig McNally File JIRAs to capture this work so it can be assigned/picked up by one of the development teams (Core platform?) - Start with a SPIKE?

Decision