Building for the Midwives of NMH, Dublin - Foundations

The first project we took on was creating an application for the midwives of the National Maternity Hospital here in Dublin. The systems used in healthcare in Ireland are mostly paper based, though there is a push towards getting all this data properly stored using technology. There are many hours wasted due to the lack of efficiency. Using the right technology these pieces of information can be input and updated instantly and will improve the health of a society.

We're going to be releasing a number of posts detailing the tech that we decided to use. This will be part 1 and we'll be talking about the base choices like language and API framework.

Language

We chose Python as the server side language. Our most recent experience was with Ruby and Erlang and though it's quite tempting to stick with the devil you know, there's never been a case where we tried something new and didn't learn a different, sometimes better, software pattern. One of the most important things that we learned from Python is:

There should be one-- and preferably only one --obvious way to do it - http://legacy.python.org/dev/peps/pep-0020/

We believe this is important because the more ways there are to do something the more can go wrong (looking at you, PHP). We did notice that it can take some time to find the way in Python. Googling answers for common web patterns takes a bit more effort than, say, Ruby. It's interesting to note the differences in community, how abundant advice is and how it spreads.

API

Flask came naturally as the next choice. It's quite similar to Sinatra in that it allows fast prototyping with little setup. It has a built in rendering engine, route handling and a good collection of libraries to fill in the gaps that are not core in Flask, like login handling, ORM and RESTful resource management. We'll be talking about these libraries in various posts over the coming weeks.

In the beginning we were using Flask's template and rendering engine, returning server side rendered pages with simple form posts. This was totally fine at the time and allowed us to form the questions that drive iteration.

Our focus shifted to a RESTful style, as the resources became well defined.  We introduced Flask-RESTful, a really nice library allowing easy definition and management of resource mapping and HTTP verbs. Here's a small example:

from flask.ext.restful import Resource
class ServiceUserResource(Resource):
    def get(self, service_user_id=None):
        pass
    def put(self, service_user_id):
        pass
    def post(self, service_user_id):
        pass
class ServiceUserSingleResource(ServiceUserResource):
    pass
api.add_resource(resources.ServiceUserResource,
'/service_users')
api.add_resource(resources.ServiceUserSingleResource,
'/service_users/<int:service_user_id>')

At this point we removed all view related code from the flask app and crafted it into an API for serving all possible clients. 

Authentication

Around the same time we built authentication into the API using Flask-Login. It's very suitable for login capabilities, session control and access control.

Wrapping up

Next part we'll talk about the database level choices including the ORM and iterative database choice.