[FOLIO-1633] Establish scheme for declaring additional backend modules within a platform Created: 28/Nov/18  Updated: 03/Jun/20

Status: Open
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Task Priority: P3
Reporter: Matthew Jones Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to FOLIO-1548 SPIKE: a lighter-weight folio/testing... Closed
relates to STCLI-15 Dynamic Okapi module installation Closed
relates to FOLIO-1632 Create lighter-weight folio core VM Closed
Sprint:
Development Team: Core: Platform

 Description   

Some backend modules are not required by any frontend modules via an interface dependency. Examples include: mod-codex-inventory and mod-audit.

To provide their functionality, such modules must be specifically chosen to be deployed and enabled with Okapi. This can be accomplished in a few ways:

  • Inclusion via script like gen-module-list for the single-server install guide.
  • Inclusion via lookup in a CLI command (This only applies to some modules with known compatibility based on the existence of others).
  • Inclusion via command-line option (--include mod-a mod-b) for the new CLI backend command

Ideally we would have a way to declare such modules within the platform itself. The platform-* repos already contain a package.json defining versions of front-end modules along with a tenant config (stripes.config.js) to select which of those modules are associated with the tenant. Using the tenant config, along with the package.json of each of the platform's front-end modules, the CLI can generate a list of module descriptors with their required backend interfaces. It may make sense then for the platform-* repo to be home for the definition for any additional modules/interfaces.

One possibility is extending the tenant config with a "requires"-like section. Another could be adding a descriptor embedded within, or beside, the platform's own package.json. Still there may be other options, perhaps introducing a higher level descriptor.



 Comments   
Comment by Matthew Jones [ 28/Nov/18 ]

The need for this came out of conversations around FOLIO-1548 Closed and STCLI-15 Closed . It is not blocking or required for such work, but having a consistent way to define additional modules/interfaces would make the process more complete.

Generated at Thu Feb 08 23:14:46 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.