User Guide

What is Solvent-ConfigNode?

ConfigNode is a configuration management environment for teams. ConfigNode uses object graphs instead of static file formats such as JSON,YAML,XML..etc to provide powerful capabilities not possible using traditional approaches.

Managing Hierarchical Configuration

Whether you're doing DevOps,Machine Learning or Web development, chances are you maintain configuration in the form of hierarchical formats such as JSON, YAML, XML..etc A key design goal for many hierarchical information formats is to strike a good balance between machine readability (parsing) and human readability.

Unfortunately no matter how human readable these formats are, they quickly become a challenge to deal with once the structure of the information becomes complex. Editing complex JSON or YAML files is a challenge. Through hyper-navigation, ConfigNode provides a number of features to make managing complex hierarchical information easier.

Object Graphs

ConfigNode is based on an object graph technology which allows a user to construct object graphs of any complexity or composition. ConfigNode can be used for everything from DevOps, ML, product catalogs, taxonomy creation...etc

ConfigNode object graphs can be integrated directly into applications. For instance a developer can use an object graph representing a product catalog to populate an e-commerce site. Because the construction of object graphs isn't based on any particular syntax, non-technical users can work side-by-side technical people, allowing all parties to contribute to the creation of products/services on a single platform.

Note that ConfigNode is a product built on top of the Solvent WebApps product platform, specifically, ConfigNode is based on the Smart Object technology of the Solvent platform. This means the ConfigNode documentation only covers functionality specific to ConfigNode. Users should consult the Solvent WebApps product documentation.

Creating and managing objects.

To create a new object, right-click on target folder and do New==>Object Structure==>Object.

Once an object has been created, fields can be added including composition of other objects.

Importing Configurations

Users can import existing configurations into ConfigNode, these can be either JSON or YAML files.

To import a configuration, download the static file then, right click on the file and do Objectify.

Note that import operations can take a while depending on the size of the configuration. The taxonomy operations of ConfigNode are inherently ineffeciate so this should be expected.

Loading Object Graphs

After and object has been created or imported, it can be loaded for further editing via right click on the object folder and selecting Explore Object==>(Lazily or Fully).

Note that ConfigNode designate folders that end in {} or [] to be object graphs. When importing external files, the file system structure that is generated is labeled in similar fashion.

From this view, you edit the object graph both by editing individual objects and by manipulated the navigational view such as drag-n-drop, copy/paste, delete..etc. Simply right click on any node to perform available actions.

Managing Object Graphs

ConfigNode object management aims to match the dexterity of a text evironment while facilitating the advanced capabilities that the object graph provides. Most object editing happens with the object editor on the right but the changes are reflected on the navigational view on the left. This makes working with ConfigNode quite pleasant.

Navigating the graph

Every object node can be opened simply by clicking on it. It is also possible to navigate a graph in a single tab view without having a new tab open for every node. To open a pin view that allows for in-place navigation, right click on an object node and select Open In Pinned Tab.

Once the graph is opened in a pinned tab, user can navigate up and down the graph in one view. Note that only one pinned tab can be open by graph.

Object Graph Schemas

ConfigNode supports schemas using JSON schema specs. If a JSON file is imported as an object graph and that file is recognized as a JSON schema (ie with a property $schema), it will process the schema and expand all $ref to create a complete object graph representation of the schema.

All schemas should be placed in the standard application directory solvent/object-explorer-schemas, including imported JSON schemas. A schemas can be placed in any sub-directories of the aforementioned base directory and ConfigNode will be able to locate it.

Schemas are also object graphs so everything that applies to object graphs applies to schemas.

Enabling Schemas On An Object

An object references a schema by setting a platform parameter solvent_object_schema. In general this parameter is something set by ConfgiNode and should not require direct user manipulation. The value of this parameter is the path of the schema relative to the directory that contains the root schema. In other words it would be the full path of the schema starting at the root of the schema but not including the file system location of the schema itself.

Creating Objects With Schemas

When a new object is created, it can be tied to an existing schema by selecting the suitable object type.

Auto-complete via Schemas

ConfigNode's schema support allows for objects to be created using auto-complete to perform lookup on available properties. At the moment there is no support for object validation but that will be added in upcoming versions of ConfigNode.

Cloning or Linking via auto-complete

When creating new objects via auto-complete, user has the option of either cloning an existing object of the same schema type or linking to such an object without cloning it into the current object graph file system structure.

Hyper Navigation

ConfigNode hyper-navigation feature allows for the seamless navigation and exploration of complex configurations. Hyper navigation allows for exploring objects from any depth of the graph Hierarchy. In other words the navigational view tab can be rooted from any point of the graph thus making it easy to work on complex configurations without getting lost in deeply nested structures.

URL Addressable

Hyper navigation isn't just a build-time capability, all Smart Objects are URL addressable, meaning a graph can be invoked from any point in the hierarchy to get an object starting at a given address.


In addition to the challenge of dealing with complex hierarchical information expressed in JSON, YAML,XML..ect, there is also the problem with these formats being static.

In other words you can only statically specify information in JSON or YAML without a default ability to generate dynamic/programmable values. New templating languages such as jsonnet,ksonnet,hocon..etc have been developed to handle this challenge with various strengths and weaknesses.

ConfigNode is based on the construction and execution of an object graph, this gives it incredible power when it comes to runtime value generation. Information can come from a full templating language, from a piece of code in any of the languages the Solvent platform supports, from a database or from user supplied parameters.

To state simply, there is no limitation to how you can incorporate runtime behaviour and data into a ConfigNode object graph.

Dependency Resolution

During the execution of an object graph, it is possible for the current object to "reach back" up the graph to aquire a value that has been computed. This feature is a mechanism for establishing a dependency relationship during the execution of the graph and gives it a powerful capability.

During the execution of an object, its caller's arguments map is accessible via the solvent_caller_context environment parameter. Using this map, an object can reach back up its graph to access dependencies.

Given the example noted above, the parameter reach_back would now point to the same object as stdin, which is two levels above, thus establishing a dependency relationship that can be resolved at runtime.

Schema Extensions

Schema Extensions are extensions to standard JSON schemas to support additional functionality in ConfigNode. Within ConfigNode, any schema can have an additional property schemaExtension.

Schema Extension Structure

  • dependencies
    • data
    • events
      • onCreateObject
      • onSchemaResolved
  • settings

Schema Events

Currently two schema events are supported. A schema can register for these events by specifying them as noted above.

onCreateObject is triggered when a new object is created.

onSchemaResolved is triggered when a schema has been resolved, typically this is after $ref path has been resolved into the actual schema.

Available Schema Actions

Events can trigger the execution of actions. The following actions are currently available.

  • applyExecutablePresets
  • mergeProperties
  • deriveFromSchemas


This action is a way to specify presets for Solvent smart objects, ie you can specify presets for parameters, pre/post execution, security. This action for now is supported as an action for the event.

There can be as many presets as needed, each preset needs to be constructed in the format of Solvent executable core elements (parameters, pre/post execution, security). Look at any Solvent executable json file for an example of the format.


This action is a way to combine properties from two schemas into one resultant property set. This action for now is supported as an action for the event.


This action is a way to combine multiple schemas into one resultant schema. In effect it is an inheritance mechanism implemented as an object composition of all parent schemas. The schemas are combined from first to last, with the referencing schema providing the final override for any parent supplied properties.

This action for now is supported as an action for the event.

Schema Inheritance

ConfigNode supports two schema inheritance mechanisms, property inheritance and full schema inheritance as specified by mergeProperties and deriveFromSchemas.

Both mechanisms are implemented as object compositions (aka mixins). Imported properties are copied into the destination schema properties object. Derived schemas are merged into the destination schema via a deep merge of all properties (ie javascript fields) in the schema being derived from into the schema that is deriving.

The end result of a schema deriving from another schema is that the resulting schema will have all fields present in either schemas, when a field is present in both schemas, the child schema's value takes precedences. A schema can derive from multiple schemas, in which case the object merge will be done from first to last, with the child schema's field values taking precedence.

$ref with super powers

Where as the standard JSON schema spec has specific places where $ref can be expected, ie mainly to serve as pointers to schema definitions, in ConfigNode schema extensions, $ref can be used in many more ways. In particular, $ref is used to allow for sharing any object definition, ie not just schema definitions. This allows for schema based solutions to share artifacts in more generic way.

Currently this can be thought of as a way to share data with schemas. Currently there are no platform level data elements but that will change as the ConfigNode platform evolves.


schemaExtension.settings can be used for certain application specific needs. There are no platform specific needs yet but that would change in the future.