Marco Vellinga - Creating abstraction between consumer and datastore

See the PyGrunn website for more info about this one-day Python conference in Groningen, The Netherlands.

Marco Vellinga is a programmer at Devhouse Spindle.

Default: web app connects to HTTP api that talks to your data store. And another web app talks to another HTTP api, and another, etcetera.

Better: let all apps talk to one data access layer. You need core logic, a contract on how apps can talk to you, validation, error handling.

Some cons:

• It is quite difficult to find information about this on the internet.
• It is a bit overkill for small projects.
• It can take a long time to build before you get it right, at least longer than we expected.

In our solution, data needs to be (de)serializable in json. We are using marshmallow.

Filtering with and/or/not. We created FilterQL.

We wanted versioning of code paths and made a decorator for this. With that, you can call method.v1() and method.v2(). You can version classes or functions this way. We created versionary. You do want some deprecation policy here: having sixteen different versions of the same function seems a bad idea.

We have something for validation too, but we are working on that, it is too verbose currently.

In the end: is it worth building such an abstraction layer? The first day this went live, we found lots of mismatched data, so it helped us find errors in the data. If you can start from scratch, it helps.