Code & words reluctantly authored by David King.

a software developer from Sheffield currently residing in Oxford.


Services in Flask

Due to the nature of Moxie and Mobile Oxford we require a highly configurable application (such that it could be deployed at another institution). There were a couple of projects out there which offer this to some degree, Flask-YAMLConfig for example. Our own attempts have produced what we've rather creatively named Services.

Services to us represent a logical chunk of functionality which can be (so far) configured centrally (this actually happens on a per-blueprint basis). Excuse the loose terminology but that should give you an idea of the goal.

So, what do Services look like? Take a look at our KVService. Usage of this Service can be found within our Celery tasks and transport views. Each time the class is instantiated from_context this means the Service accesses its own *args and **kwargs from a per-blueprint configuration. In other words:

The same Service accessed within calls to views registered by separate blueprints will have separate configurations.

What's more, you can safely rely on the fact that within a single request Services accessed through from_context will always return the same object. See the tests for examples of this behaviour.

The API can be further sugared by using a LocalProxy:

kv_store = LocalProxy(KVService.from_context)

We're still actively working on this approach, but so far I've been pleasantly surprised with it. We have fine-grained configuration and a clear separation between application logic and the transport layer.