Why we ​transitioned ​from a Drupal ​CMS to an API-​based ​Architecture ​

At ​​TallyFox we have a Vision to ​​“​​Bring ​​together ​​the ​​collective ​​​​intelligence of ​​​​professionals ​​​​to create a ​​​​better ​​​​future”. ​​​​Our solution ​​is  ​​a ​​contextual ​​​​knowledge ​​​​sharing ​​​​platform to ​​​​make it happen. ​​​​Drupal was ​a perfect fit for ​​​​what we ​​​​envisioned.​​ ​ ​​ ​ ​

Our journey ​from a Drupal ​CMS-based, ​knowledge ​sharing ​platform to an ​API-based ​architecture, ​knowledge ​sharing ​platform has given us incredible insight into the industry, ​and we would ​like to share ​it with you. ​

So let’s go.

When we were ​​​first ​designing ​​a ​solution, Drupal was THE best way to go. ​​​After all, ​when ​​it was ​ ​​officially ​​​released in ​​​February ​​​2008, Drupal ​6 ​​promised to ​be ​​“the ​​​easiest ​version ​​of ​Drupal ​​​ever”, ​​​backed up by ​​​its plethora of ​​​tools and ​​​features that ​​​were supposed ​​​to change the ​​​open source ​​​world forever.​​​  ​

​ ​

For us, ​​​Drupal seemed ​​​ideal.  ​ ​​

It was open-​​​source with a ​​​big community ​​​behind it and ​most of the ​​​functionalities ​​​were already ​​​developed in ​​​their modules ​​​or could be ​​​developed ​​​easily. ​

It was ​​a ​fast ​​​prototyping ​​​version we ​​​needed to ​​​confirm our ​​​business model, ​​​and we ​​believed ​that ​we could ​further advance ​our solution ​with it. ​

So what was ​the issue with ​Drupal? ​

Let’s start with ​Bootstrap. For each page requested Drupal executes the entire bootstrap process. We had ​around 270  modules and they were all connected which implies that the whole code was read each time you open a page.​ There wasn’t an option for only a part of the code to be read. This brought up speed issues which we were able to resolve after a year of hard work.

But the number of modules brought up security issues as well and we weren’t happy about  them either.

You need to know that the Drupal template engine is very aged, and very slow in Drupal 6 and 7, and our platform had a lot of custom template files. Not all modules worked the same way when moving from one version to the next.  As we worked ​on the platform,​ it ​​became ​more and ​​more ​bloated ​​and ​technically ​​​difficult to ​​​maintain every ​​​time a new ​​​feature or ​​​option was ​​​added to it.​​​ This made a ​​​​personalised ​​​​solution nearly ​​​​impossible ​if ​​we wanted the platform to meet our standards. ​

Also, as the ​numbers of client ​communities rose, system load rose ​as well and it wasn't scalable going forward. It ​came down to ​changing ​Drupal, BUT, if ​we’re ​already working ​on adjusting ​Drupal, why not ​choose a ​framework and ​build a new ​architecture? ​We chose Symfony.

One of the ​deciding ​factors was ​that our ​potential ​​​clients had ​​​specific needs ​​​in terms of ​how ​​they ​wanted to ​​​start and grow ​​​their ​​​communities. ​​​Some of them ​​​already had a ​​​legacy software ​​​that they ​​​didn’t ​​​want to give up ​​​on and there ​​is ​also a ​​​prevalence of ​​​many consumer ​​​apps that are ​​​moving into the ​​​business ​world ​​that ​needed to ​​be ​integrated. ​

We needed an API-based ​architecture if ​we wanted to ​evolve to ​​​support the ​​​communities of ​​​future which ​​require ​to be ​​​personalised ​so ​​each ​person ​​gets ​information ​​​specific to ​​​their interests;​ ​configurable, ​​​highly ​​​integrated ​​​through APIs, ​​​and compatible ​​​going forward. ​​​

An API-based ​​​architecture ​​​essentially ​​​acts as a lego ​​​platform, ​where ​​you can ​attach ​​​different lego ​​​blocks in ​​order ​to build ​​​exactly what ​​​you need. This ​​​also means ​that ​​you can ​easily ​​add or ​replace ​​​specific ​​​components ​​​without ​​​necessarily ​​​having to waste ​​​the work done ​​​on the ​existing ​​ones.​

With Drupal ​it was ​difficult to ​even rename a ​feature. Now we ​can not only ​rename a ​feature, we can ​configure the ​whole platform. ​

Why is ​an API-based ​architecture ​the right ​solution for us?​

We envisioned ​​​an open-​​​knowledge ​​​concept - A ​​knowledge ​​​sharing ​​​platform where ​​​knowledge is ​​​not siloed, but ​​​shared across ​​​instances and ​brought to you ​through ​contextual ​knowledge ​sharing. We ​enriched it ​with Smart ​Match Pro, our ​algorithm, ​which only ​flourished when ​we included ​technologies ​such as graph-​base to make ​sure that ​relevant ​content is ​delivered to ​platform's users, and ​the relevance ​percentage is ​calculated ​based on your ​industry ​expertise. ​

When we say ​contextual ​knowledge ​sharing, we ​mean it's ​not just that ​the information ​is suggested to ​you: It's ​all the aspects ​around it which ​give it "​context" - Who ​shared it, how ​is it ranked ​and tagged and ​how it ​is relevant to you.​

It took us a ​couple of years,​ and in May ​2015 we ​officially ​launched ​Tallium, an API-​based ​architecture, ​knowledge ​sharing ​platform. ​Looking back at ​Drupal 7 and ​Drupal 8, we ​made the right ​decision. ​