Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Info
titleWIP

This page is a work in progress

...

Already exists, fetching and processing the configuration JSON works just the same as any other data JSON.

Examples

Several modules already use "Distributed Configuration via Path", see these examples that show CRUD configuration APIs:

Module, type of configurationPath

mod-inventory/inventory-config

/inventory/config

mod-invoice/batch-voucher-export-configuration

/batch-voucher/export-configurations

mod-invoice-storage/batch-voucher-export-configuration

/batch-voucher-storage/export-configurations

mod-orders/configuration

/orders/configuration

mod-orders-storage/configuration

/orders-storage/configuration

mod-event-config/event_config

/eventConfig

mod-data-import-converter-storage/form-configs-storage

/converter-storage/forms/configs

...

  • Doesn't require use of an additional headers or additional parameter
  • No change needed in Okapi and Stripes
  • Front-end can use existing standard stripes-connect and standard JSON processing methods.
  • RMB provides default CRUD implementations for the storage module: PgUtil.get, PgUtil.put, PgUtil.post and PgUtil.delete that reduce the implementation to a one-liner per HTTP method (mod-orders-storage example).
  • Is in line with existing path-based configuration storage APIs (see list of examples above)
  • Both simple and complex configuration options use the same path based syntax
  • Doesn't introduce yet another configuration interface syntax (like "Multiple Interfaces and Scope", or "Namespace")
  • Each module has its own configuration interface.
    • This allows for detailed module-specific API description that can be added to the API endpoint documentation at https://dev.folio.org/reference/api/
    • The configuration interface version tracks changes that affect only configuration; this is not possible if all modules share the same interface.
    • Allows other modules to depend on the specific configuration interface.
    • The individual interfaces avoid the architectural design smell that a common interface creates. A common interface should only been used for the same option (for example a timeout option) or if the configuration is stored in a central configuration service module.

...

  • Every implementation of configuration is different, meaning separate implementations and separate client code is needed. However, this code can be extracted into a method for re-use, and the method calls differ by parameter only. The same applies to the multiple interface solution and the namespace solution.
  • Each module has its own configuration interface resulting in more paperwork when comparing to the existing mod-configuration solution; the multiple interface solution and the namespace solution also require interface paperwork for each module.