By Andrew Boag
Web services are no longer an after-thought in application design in these times and to support the data interchange in one of our recent application projects we were in need of a REST API server.
Fortunately, the open source world has a wide range of web service toolsets with support for sending and receiving web service messages using standards-based protocols.
In this particular project, Catalyst had almost free reign to choose the right tool for the job. The core functionality being to act as a Web Server for incoming REST API messages from all over the Internet.
What About Using a Full Web Application Framework?
During our initial architecture brainstorm and prototyping phases, we were leaning heavily towards the application framework django - https://www.djangoproject.com. We threw some time at a basic prototype.
The team working on this were not django experts. In a way this was useful as we were going to be doing some non conventional things with our web service engine and we wanted to understand the learning curve for ramping up new developers and ongoing maintenance later on.
Thankfully, other parts of Catalyst have considerable django experience and this was invaluable during the prototype phase.
Django gives you a lot in terms of front end and a huge amount of useful tools around data storage and validation, but it also imposes a certain level of structural compliance onto your application. In the initial phase of development, this felt more like a hindrance than an advantage.
Given that our prototype was working from the web service outwards (we didn't care much about look and feel of the application to begin with), there was too much in django that we did not fully understand involved as part of getting a basic web service running. This made us a little uncomfortable. It's fair to say that in retrospect, with the right “django champion” we likely could have made django work just fine.
What about Using a CMS?
Drupal was considered, and we were confident that a basic prototype would be fairly easy to bang together without too much coding.
However, the main pitfall with using Drupal was that often the Drupal application needs to be fully bootstrapped in order to do anything that involves internal data state change. There are valid reasons for Drupal doing this, but it would mean in our case that even a simple operation that may be only a single insert into a database table would trigger a large activity footprint on the web server … something that we had seen before and wanted to avoid.
Hence, we ruled out basing our solution Drupal.
Along Came Python Flask …
One of the team members proposed Python flask - http://flask.pocoo.org - as an option. We had used it once before on an unrelated project and had positive experiences with it.
Flask is open source (BSD Licence) and is billed as a “microframework”. With an active development community and plenty of documentation.
We installed the latest version and found that we were able to quickly and easily build a basic RESTful web service provider. Exactly what we wanted.
After the initial progress, we were very quickly able to focus our energies on implementing the required business logic and process required behind the web services. Getting to work on the meat and potatoes of the solution.
We are happy with the direction that we have taken, and this is another great example the enabling factor of using open source software to deliver solutions for our clients. Looking forward to finding other great projects where we might be able to use the flask framework.