For my first "real" post after my extended leave, I wanted to cover something fun (well, fun if you like writing libraries with Flask and SQLAlchemy...). In one of my projects at work recently, I was tasked with turning a client-facing Flask app that I had written into a framework/library that made creating new "sub-applications" as easy as possible. One pattern that had worked well in the original app was the use of Flask-SQLAlchemy, both for interacting with a new set of database models and in connecting to existing databases owned by other teams. One existing database, in particular, was heavily used by the app and would likely be used a good deal by any "sub-apps" created on the framework.
The database in question was essentially our company's "main" database, with
about 100 tables (each with thousands or millions of records). This is a common, and somewhat frustrating situation when writing internal libraries: you know clients are going to need to use some resource, but you're not exactly sure how or what parts of it. How do you create an interface to that? With SQLAlchemy specifically, does that mean each sub-project will need to describe all of the tables it needs to use from the "main" database, leading to repeated, boilerplate code? Of course not! All it takes is a little magic.
Read on →