The focus of REST access to Domino seemed predominantly based on reproducing the style of access to other NoSQL backends. Namely REST access for basic CRUD operations: the ability to create, read, update and delete documents. This is what Domino Access Services provided, albeit imperfectly because read operations provided far more than was necessary and create / update operations provided unsatisfactory options for validation. And the demos I’ve seen of migrating Domino apps to other NoSQL backends focus on migrating apps where basic CRUD operations are sufficient – for example the Discussion Template.
But Domino pre-dates REST access to NoSQL databases. It predates basic CRUD access to backends. Consequently interaction with the NSF is via a much more sophisticated set of APIs – whether that be in Formula Language, LotusScript, Java or a mixture of one or more of those. Even where interaction with the NSF was from a browser, although Read access might have been via URL commands that gave basic CRUD operations, rarely was that sufficient for a Domino web application. Instead, there were URL commands for ?openAgent and, more recently, URL command access to web services. Agents and web services then used the more sophisticated and flexible backend languages. This is a key factor worth bearing in mind and not forgetting in the desire to embrace what’s “cool”.
What Is The Sweet-Spot for Domino Applications?
And this brings me to the other key factor. Despite the main IBM templates, the vast majority of Domino applications focus on a common purpose: workflow. One of the other key aspects of Domino is hierarchies, namely parent and child documents, related for a specific reason. CRUD, however, focusses on creating a single document, reading a document or collection of similar documents, updating a document, deleting a document. Actions performed in Domino applications are updates to approval fields on documents that are not exposed to editability via normal CRUD operations, sending notifications at the same time as an approval or CRUD operation, updating a parent and associated children at the same time, or updating a child and associated parents at the same time. This is not done by separate CRUD actions, as with other NoSQL databases. Because Domino has a sophisticated and flexible set of backend APIs, it’s done in a single chunk of code – behind a button, in a querySave / postSave event, in an agent etc. CRUD could be used to change the status of a document, but would not as seamlessly update a set of related documents, or send an email, or create another notification document, or post to Watson Workspace etc.
The Elephant in the Room
For me, so many Domino apps are intrinsically linked with custom workflow and a single update process updating multiple documents, that it seems unnatural to try to shoehorn into CRUD operations what has been natural and straightforward using the Domino APIs. And the custom functionality required is too varied to expect a template from IBM to provide this kind of functionality. There are a variety of options, both provided by IBM (Extension Library or agents if you wish) and from the community (SmartNSF, ODA Starter Servlet). These are a better fit for the kind of functionality I tend to see in most of the applications I’ve built.