[FOLIO-3105] SPIKE: Investigate OKAPI extensions to accommodate things like distributed configuration Created: 07/Apr/21  Updated: 21/Jul/21  Resolved: 19/Apr/21

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

Type: Task Priority: P2
Reporter: Craig McNally Assignee: Craig McNally
Resolution: Done Votes: 0
Labels: R2, platform-core
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to FOLIO-3121 Define the distributed_configuration ... Open
relates to FOLSPRINGS-18 Default implementation of the distrib... Open
relates to OKAPI-1008 Namespace-scoped Interface support Open
relates to RMB-827 Default implementation of the distrib... Open
relates to STSMACOM-499 Support for consuming the distributed... Open
relates to UXPROD-3018 Distributed Configuration Open
relates to FOLIO-2875 SPIKE: how to distribute configuratio... Closed
Sprint: CP: sprint 112, CP: sprint 111
Story Points: 2
Development Team: Core: Platform
Release: R2 2021

 Description   

Overview

Following FOLIO-2875 Closed we want to investigate options other than the multiple interface.

Provide a way for modules to implement a common interface, with some easy way to tell OKAPI which one we want to call.

Requirements

  • Should not require use of additional X-Okapi-* headers
  • Must be able to depend on the interface
  • It's use should be Optional
  • Clients should not be required to know/determine the module Id in order to call a specific implementation of the interface.


 Comments   
Comment by Jakub Skoczen [ 07/Apr/21 ]

Craig McNally Adam Dickmeiss I was thinking about something like a new parameter called "namespace" that would allow is to implement a regular interface by more than one module. Example:

{
  "id": "mod-hello-foo-1.0.0",
  "name": "Hello foo module",
  "provides": [{
    "id": "configuration",
    "version": "1.0",
    "namespace": "foo"
    "handlers": [{
      "methods": [
        "GET"
      ],
      "pathPattern": "/config",
      "permissionsRequired": ["foo.config"]
    }]
  }
}

and

{
  "id": "mod-hello-bar-1.0.0",
  "name": "Hello bar module",
  "provides": [{
    "id": "config",
   "namespace": "bar" 
    "version": "1.0",
    "handlers": [{
      "methods": [
        "GET"
      ],
      "pathPattern": "/config",
      "permissionsRequired": ["bar.config"]
    }]
  }
}

Okapi then would mount the endpoint with an additional path prefix that takes the value of "namespace":

/foo/config/
/bar/config/

Additionally on the "requires" end Okapi would allow to depend on an interface in a specific namespace, like so:

  "requires": [
    {
      "id": "config",
      "version": "1.0"
      "namespace": "foo"
    }

All (exiting) implementations that don't specify an explicit namespace would be considered in a ":default" namespace.

Comment by Adam Dickmeiss [ 07/Apr/21 ]

Looks good to me.. I would have suggested to reuse the scope for this.. But perhaps it's just better to add a new property (the scope was an array as well !). We could be more explicit with the path patterns.. eg

{
  "id": "mod-hello-foo-1.0.0",
  "name": "Hello foo module",
  "provides": [{
    "id": "configuration",
    "version": "1.0",
    "namespace": "foo"
    "handlers": [{
      "methods": [
        "GET"
      ],
      "pathPattern": "/{namespace}/config",
      "permissionsRequired": ["foo.config"]
    }]
  }
}

or even even:

   "pathPattern": "/{namespace}/{version}/config",

if you want the interface version to be part of it too .. or

   "pathPattern": "/{namespace}/{version}/{id}",
Comment by Adam Dickmeiss [ 07/Apr/21 ]

Jakub's suggestion would be a P3 in effort, I reckon. So this could be delivered for at least one module to use for P2 (like a PoC).

Comment by Jakub Skoczen [ 08/Apr/21 ]

Adam Dickmeiss if we re-use 'scope' for this are we going to have a problem ensuring that only one implementation of a given interface can exist per scope? If not, then I don't see a problem. Though I don't see much value in being able to specify multiple 'scope' values.

Regarding making the path more 'explicit' – I am not sure it's a good idea. I am concerned that it would make it harder for the client/UI code to call the ednpoints. How would they know how to supply the 'scope' in the request? I think we should have a "fixed" calling convention for this that is not configurable. We could make the path component a bit more special (similar to the /_/invoke mechanism) e.g /_/scope/bar/....

Comment by Craig McNally [ 12/Apr/21 ]

Jakub's suggestion would be a P3 in effort, I reckon. So this could be delivered for at least one module to use for P2 (like a PoC).

Adam Dickmeiss can you please clarify what you mean by a P3 in effort?

Comment by Craig McNally [ 12/Apr/21 ]

See https://folio-org.atlassian.net/wiki/display/DD/Distributed+Configuration+via+Namespace

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