Is nodlin the right tool for the job?
Nodlin is not suitable for all types of problem. The following should be considered when deciding if nodlin is the right tool for your use case.
Guaranteed consistency
Nodlin is not suitable where guaranteed immediate consistency is required.
That being said, you should question whether that your requirement is correct. If you are performing some accounting and you want to perform a debit & credit across 2 accounts, then yes, guarantees are required.
If your application requires or produces detail for other systems to consume - then the detail shared with those other systems is operating in an eventual consistency model anyway.
If you want to guarantee consistency across nodes then you can handle this through an external agent. In the accounting example noted above, if you have an external system of record (aka a database), you could apply the single transaction to debit/credit and ensure consistency. The external agent would provide the necessary updates to both nodes and request nodlin to update the nodes on the response. Be aware however that these will be processed by nodlin as 2 operations, so your SOR may not be in line with the nodlin record. This will be visible in nodlin if a node is not in-line with the version of the related nodes.
Number of immediate relationships & volume
A node may have multiple relationships. In nodlin, when an action or event is processed on a node, the node payload and all related node payloads (with associated versions) is retrieved and the new node state is computed. The result is recorded together with the versions of all related nodes on which the action or event was performed.
It is therefore not efficient to have a large number of relationships from a single node. We currently have a limit of 10MB on the size of the combined node payloads, and including the form and image detail for the central node. This would allow quite a large number of relationships, but as a rule of thumb - if you are considering >20 relationships you should re-consider your approach. Visually this would not be appealing for the user.
If you have a large tree like graph structure, then intermediate nodes can be used to summarise intermediate levels.
Looking at the finance script for example, the sum date vector node type summarises ‘adjustments’
and presents the summary to other sum date vector nodes.
Introducing the intermediate nodes will reduce the number of relationships from a single node, but will increase the computation time for changes to propagate across the graph.
There are many performance tests on the internal nodlin processing (not published) - but the following provides you with an idea of the order-of-magnitude performance impact of any design:
Conceivably, nodlin could process any number of nodes if appropriately configured with a limit on the number of immediate relationships. Internal testing of an accounting structure creates a chart of accounts, with each account having 5 children to a depth of 6 levels (19,531 nodes). 20,000 ‘postings’ are applied to random accounts and the ’top level’ account was verified to ensure this was equal to the net of the postings. It took 6 minutes to balance these postings over 57,000 operations, taking 6.8m/s per operation. Note that there are multiple operations for each posting to account for propogation of change (accounting for operation de-dupes).
It is not advised to use nodlin for this type of use case. Nodlin is a ‘user’ based tool (typically low volume). An external accounting system could be wrapped to provide nodlin with the higher level net detail to support user analysis in nodlin. In the ‘accounting’ domain nodlin could be used to handle the ’exception’ workflow, or support high level financial planning.
[Test performed locally on M4 Mac Mini, across 4 services (dummy account service, postings, dragonfly cache, nodlin) and all connected over NATS messaging.]
User Interface Requirements
If there are rich UI requirements that are outside of the general form controls in nodlin then nodlin may not be the right tool.
The nodlin perspectives may also not be rich enough to support your UI requirements to visualise your node detail.
Nodlin however could be used to supplement your application UI (e.g. handle workflows, confirmation etc) to provide the benefit of these capabilities that are centralised from a user perspective.
Note that additional form controls can be provided and will be extended over time (e.g. geo-location control). Additional perspectives can also be added. These will only be provided if there is general applicability of these controls/perspectives.
An additional requirement is being considered where nodlin allows for a callback (URL) to external agents that provide web endpoints for more specialised views.
