JSON Store

The JSON store is a cloud repository of all config files. A simple REST API provides access to read, create and update them. No deleting is possible! The data is all stored in an Apache CouchDB database, but access is only possible via the API.

Key Requirements are:

  • Should each JSON doc have a customer label, so a customer’s processes can only access JSON docs with that label and ALL.
  • Each record has a type and a name.
  • The Type specifies the template to be used for that type of JSON doc.
  • Name is a short text identifier, which may be used by other templates.
  • History needs to show who made what changes and when. By deafult, unless you clear
  • Each JSON doc has a top level element called bazicloud, which includes type, name, created (as timestamp) and updated (as timestamp). Other fields may be added later such as customer and username.
  • Any JSON doc without a valid bazicloud record shall be automatically purged!
  • Any JSON doc of a type requiring a customer short-code but does not contain a valid one shall be automatically purged.
  • When creating docs of types requiring a customer short-code, only allow creation if the customer shortcode is provided and enabled.

Template Type

Might need a better name. There should be a type of JSON doc which either has a type of Template or a customer name of TEMPLATE which holds the JSON spec of that type of document.

Need For Customer Field

All settings should be per customer. Should there be an extra field in the bazicloud element which is the customer short code?

With docs like automations, the name should be unique per customer; but different customers may have similar automations which could have the same name. Barring name clashes between customers is an information leak and may cause confusion. So customer short code should preceded all document names, as well as being present in the bazicloud element.

Document Name

Shall be comprised of:

  1. Customer short code in uppercase
  2. ‘-’ a hypen character
  3. Document Name in Camel Case.

With the exceptions of:

  • Customer Configs shall be named as the shortcode only.
  • Global templates shall be named as just the Docoment Type. Customer specific templates can be used, which will use the stabndard naming convention.

Template Search Path

To find a template, first try for customer specific template, then fallback to global template if no match found.

  1. Try Template/SHORT-DocumentType
  2. Try Template/DocumentType

Customer Config

Customer Config shall be a JSON doc of type Customer and named as just the short code in uppercase. Customer config should include:

  • Server and path to primary file server
  • identifier for docker host
  • IP Subnet/ docker network name for all relavent Bazicloud Services
  • ? contact info
  • main colour scheme
  • path/ URL to logos

Reserved Customer Short Codes

There are 3 specicial short codes:

  1. TEST - used for testing
  2. BAZIC - used for BaziCloud
  3. SYS - used to internal purposes

Special Types

Most JSON docs will be configs for customer apps or automations. However there are a few special document types:

Type Name Comments
Customer Customer Short Code JSON doc per customer. JSON Store only allows one doc of each type and name, so this guarentees customer short codes are unique.
Template Document Type a JSON definition of the structure of JSON documents for applications or automations.
List Field Name a JSON definition of how to get allowed field values for various types of field. A doc template template can specify a field has allowed values as specified by a data source. This specifies how to get a list of possible values, usually an API call to an app or a JSON doc.
Validator Field Name a JSON definition of how to validate a typed-in value, e.g. allowed characters, minimum and maximum lengths etc.
AppConfig Application Name Application Specific Config, customer shortcode required
Automation Any Name Trigger and Action for automation , customer shortcode required

Validating changes

  • How can changes to JSON docs be validated?
  • Can we detect changes to templates that break documents, and vice versa? Should be able to do this, check that a list of documents are valid with a new template. We need some new code to check a document is valid against template.
  • How can changes to templates be made without breaking documents. We must have optional or either/or fields, then a programmatic transform from an old type to a new type.
  • What about non-templates/ non-templated data? Are there any?

How to Validate a Document and Template Pair

Is this the same problem as loading a JSON doc into the JSON editor, ie apply values from document to each element of a template, creating optional structures etc as it builds?