| Table of Contents |
|---|
...
An investigation (
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
{
"id": "mod-hello-foo-1.0.0",
"name": "Hello foo module",
"provides": [{
"id": "foo",
"version": "1.0",
"handlers": [{
"methods": [
"GET"
],
"pathPattern": "/foo",
"permissionsRequired": []
}]
},
{
"id": "distributed_configuration",
"interfaceType": "multiple",
"version": "1.0",
"handlers": [{
"methods": [
"GET"
],
"pathPattern": "/configurations/entries",
"permissionsRequired": [ "foo.configuration.entries.collection.get" ]
},
{
"methods": [
"GET"
],
"pathPattern": "/configurations/entries/{id}",
"permissionsRequired": [ "foo.configuration.entries.item.get" ]
},
{
"methods": [
"POST"
],
"pathPattern": "/configurations/entries",
"permissionsRequired": [ "foo.configuration.entries.item.post" ]
},
{
"methods": [
"PUT"
],
"pathPattern": "/configurations/entries/{id}",
"permissionsRequired": [ "foo.configuration.entries.item.put" ]
},
{
"methods": [
"DELETE"
],
"pathPattern": "/configurations/entries/{id}",
"permissionsRequired": [ "foo.configuration.entries.item.delete" ]
}],
"scope": ["foo"]
}],
"requires": [],
"launchDescriptor": {
"exec": "node hello_foo.js"
}
} |
...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
{
"id": "mod-hello-bar-1.0.0",
"name": "Hello bar module",
"provides": [{
"id": "bar",
"version": "1.0",
"handlers": [{
"methods": [
"GET"
],
"pathPattern": "/bar",
"permissionsRequired": []
}]
},
{
"id": "distributed_configuration",
"interfaceType": "multiple",
"version": "1.0",
"handlers": [{
"methods": [
"GET"
],
"pathPattern": "/configurations/entries",
"permissionsRequired": [ "bar.configuration.entries.collection.get" ]
},
{
"methods": [
"GET"
],
"pathPattern": "/configurations/entries/{id}",
"permissionsRequired": [ "bar.configuration.entries.item.get" ]
},
{
"methods": [
"POST"
],
"pathPattern": "/configurations/entries",
"permissionsRequired": [ "bar.configuration.entries.item.post" ]
},
{
"methods": [
"PUT"
],
"pathPattern": "/configurations/entries/{id}",
"permissionsRequired": [ "bar.configuration.entries.item.put" ]
},
{
"methods": [
"DELETE"
],
"pathPattern": "/configurations/entries/{id}",
"permissionsRequired": [ "bar.configuration.entries.item.delete" ]
}],
"scope": ["bar"]
}],
"requires": [],
"launchDescriptor": {
"exec": "node hello_bar.js"
}
} |
...
- Apparently it's not possible to specify a dependency on a multiple interface, so clients will need to.
- It might be helpful to extend/enhance some of the OKAPI APIs for querying interfaces
- Extending the provides query to allow the specification of a version could be helpful, e.g.
/_/proxy/modules?provide=distributed_configuration:2.0&scope=orders
Possible JIRA needed - Extending
/_/proxy/tenants/{tenant}/interfacesmay also make sense Possible JIRA needed
- Extending the provides query to allow the specification of a version could be helpful, e.g.
- If the interface is being changed often it could become a pain for modules which require the distributed_configuration interface. As a point of reference, mod-configuration's configuration interface has been at 2.0 for 4 years now, so it seems unlikely that we'll need to change this frequently.
...
- A naming convention will likely help here.
- scope is an array, so maybe it should be a list of the interfaces provided by the module, or at least those which store configuratioconfiguration
- Should a uniqueness constraint be placed upon "scope"? How should clients handle the case when multiple module IDs are returned from a query using scope?
What about business logic modules?
- One reason I think mod-configuration has been so widely adopted is that there's a low barrier to entry - just make a couple API calls. You don't need to deal with databases, etc. This is ideal for UI modules as well as business logic modules. Pulling postgres into all those business logic modules is probably not desireabledesirable. However, most of the business logic modules have a corresponding storage module. These are a more natural place to store the configuration. The BL module would call the storage module to get config entries instead of calling mod-configuration - seems simple enough. The UI could either call the storage module directly (I know some ui UI modules do this already), or the BL module could also implement the distributed_configuration interface, and act as a proxy to the storage layer. It could be handy to have a default implementation of this too. Possible JIRA needed.
...
JIRAs
Jira Legacy server System JiraJIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key FOLIO-2875