Page tree
Skip to end of metadata
Go to start of metadata


This decision has been migrated to the Technical Council's Decision Log as part of a consolidation effort.  See:  DR-000028 - FOLIO should define a minimal platform


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.


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.



  • 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?




OutcomeA "platform-minimal" should be defined which constitutes the absolute bare-minimum set of modules needed to run FOLIO
Created date


  • No labels


  1. I've spoken to Steve Osguthorpe 

    It's been a while since he investigated this. He provided me with starting point (for defining users and logging in) that I think we can use:


    The versions of pre-2021 R2. I think the list seems about right to me.

  2. The UI handles auth-n in @folio/stripes-core, not @folio/users; it directly relies on users-bl, authtoken, and configuration. Due to packaging @folio/stripes-smart-components within @folio/stripes, there are also dependencies on notes, tags, and password-validator; these should be made optional interfaces with a minimal amount of effort. 

    It looks like we could significantly prune the dependency tree if we rewrote authentication directly in terms of login (depends on users), authtoken (depends on permissions, users, both pure), and configuration (pure) instead of in terms of users-bl which requires users, permissions, login, service-points, service-points-users, password-validator, authtoken, notify, and configuration

    This would also make that "minimal" platform significantly/completely library-agnostic, which I think would be a major win from the point of view of FOLIO as a generic application development platform rather than as a library application development platform.

  3. Starting with the snapshot-backend-core Vagrant image, I was able to pare things down to six services, plus okapi, and still send a successful authentication request:

    vagrant@vagrant:/etc$ docker ps --format '{{.Image}}'
    vagrant@vagrant:/etc$ curl -v --location --request POST \
    'http://localhost:9130/authn/login' \
    --header 'x-okapi-tenant: diku' \
    --header 'Content-Type: application/json' \
    --data-raw '{
    "username" : "diku_admin",
    "password" : "*****"

    * upload completely sent off: 55 out of 55 bytes
    * Mark bundle as not supporting multiuse
    < HTTP/1.1 201 Created

  4. This was a first step with minimal effort, just shutting down modules until auth-n failed and it was really easy to show here. It'll take some Real Work to get the UI running because it'll have to be refactored away from bl-users/login?expandPermissions=true&fullPermissions=true  to authn/login. That means not only a different login-endpoint but also an additional query to get the user-data (authn/login for some reason returns the username and password (?!?) instead of a user-id). It shouldn't be a huge effort, but it's bigger than just flipping some modules off.

    1. Actually, it wasn't that much work. By tweaking stripes-core and adding extra requests to retrieve the user and permissions, it is quite easy to create a no-app platform that supports nothing except authentication. 

  5. This is really great progress. Is there any way to avoid the dependency on mod-login-saml? SAML-based SSO support seems a strange requirement for a minimal platform.

    1. Yeah, we can knock out mod-login-saml , too. That was just an oversight on my part. Again, it'll take some work to get stripes-core  and ui-users  properly cleaned up to function without all these modules running, but I think that's of more limited value personally, unless there's some huge contingent of UI devs out there building apps on the stripes framework and not telling us about it. 

      1. I think part of my issue with `mod-login-saml`, particularly, is that it is something of an orphan module and keeping it a dependency for stripes-core seems to expose the project to some risk.