Over the last few weeks for a proof-of-concept project we’ve needed to produce a decision tree containing a bunch of custom questions to led the user to the right service. We also needed to use Natural Language Processing to then triage a user’s request and direct them to right part of the tree, and because we were rapidly iterating the structure, we also needed a NoSQL database to store the user’s decision path.
Heavy introduction, I know. I wanted this blog to discuss how we implemented the solution to this problem, rather than dwell on the customer problem, which is more related to my paid employment, than my personal blog.
So without further ado, I won’t refer to the problem (which is a bit of a cardinal sin) and just focus on the tech used to solve this unspecified problem. Rest assures, the solution did follow the problem after customer insight and strategy development, so it was done the right way around.
But back to the solution (the fun part)…
We had a small team, and two weeks to build the solution – and it was proof-of-concept, so it had to demonstrate what was possible, rather than be too constrained with production considerations.
I was acting as PM, and also looking at the CMS and content structure side, and we had our front-end and back-end developers looking at Natural Language and constructing the decision tree. Immediately, I thought of Drupal, as there wasn’t much time and I needed to create a large content structure quickly in something I was familiar with. However, this wasn’t well suited to the Natural Language Processing (Python), AngularJS front-end and MongoDB chosen to store the user preference on the decision tree.
So decoupling it is.
So we built up the content types to represent the decisions (queries, responses, and linkages), as well as the services that represent the end points of decisions. This was then mobilized via Drupal Services as an API, which could be consumed as a backend for the Django / AngularJS front-end of the web service.
Too complicated? Well it was risky to develop up in a few days, but it worked. And importantly, I could see some real benefits to this approach.
For me, Drupal biggest strength has been its backend and structure. I was able to leverage this, as well as Views as a way to visualise, manage and organise the tree. Also, little tools like node clone were a life-saver when creating some of the more repetitious parts of the tree.
And in terms of using the strengths of Python for language processing, and AngularJS as a seamless way to navigate the tree, we could iterate rapidly, without needing the customise the Drupal front-end.
But perhaps most importantly, I was adding attributes to the services quite rapidly as we finalised requirements throughout the sprint. Needing to rebuild a relational DB for each change would have been a nightmare. Thus using MongoDB was really important to enabling this rapid change (I just had to remember to update the block used for the API).
So in all, I recommend it. Drupal’s power for content management, visualization the administration side, and providing an API for consumption by other web apps. Go team!