5 ms·

Writing a shared app shared database tenant isolation database middleware for Django was one of the most interesting challenges I’ve had over the years. The lib

Writing a shared app shared database tenant isolation database middleware for Django was one of the most interesting challenges I’ve had over the years. The library was 100% tested with Hypothesis to randomise the data, and used ULIDs to allow for better long term tenant sharding and since ULIDs are compatible with UUIDs they can be dumped/propagated into other systems for analysis/analytical queries. It was quite a lesson in what 100% test coverage does not actually prove since I still had bugs at 100% coverage that took work to chase down, side effects, false positive/negatives, etc.

sirkarthik 6y ago
Thanks for sharing your experience. Mind sharing the details of the bugs and the middleware you were writing. IS that an open-source library that I can take a peak into?
- techdragon 6y ago
  I ran into so many interesting bugs, I’ve honestly forgotten most of them, but I do remember many of them were actually to do with extensive use of UUIDs and the interaction it had with more powerful Django ecosystem tools that did things like expose a complete JSON-API endpoint, stuff that did “query building” was generally not designed with accounting for. My favourite is having to selectively use thread locals to disable the query filtering layer for very specific internal queries that a few libraries used. I tried to get it working with context vars for future Django async support but never had the time to finish that work. The code was written with open sourcing it in mind actually. The amount of effort involved pushed me to select License Zero effort and specifically the Prosperity Public License https://prosperitylicense.com https://prosperitylicense.com (License legal TLDR is “open” but if you use it to make money you have to pay me something I agree to) I’m hoping to do a significant refactoring before I mark the 1.0 version. I have some ideas that may be vastly cleaner but really requires nailing the whole thread local / async context vars lifecycle so I’ve kind of tried to limit who might start relying on it based on how extensively tested it is.
squeaky-clean 6y ago
I lead a service that's used by about 30 airlines and did pretty much exactly the same thing. Django middleware, ULIDs, and using hypothesis for testing. I also extended the django ORM to help restrict what sort-of queries are even possible and to improve error logging for our use cases. As an extra bit of security and logging, ICAO codes everywheeeere. It's a good thing we don't sell to non ICAO airlines. I can also anecdotally confirm the statement in another user's comment about 1 tenant using 60% of everything. And it's not even a large airline! This one relatively small carrier uses more of our resources than AA, UA and a few of the other top 10 global carriers combined.

sirkarthik 6y ago

Thanks for sharing your experience. Mind sharing the details of the bugs and the middleware you were writing. IS that an open-source library that I can take a peak into?

techdragon 6y ago
I ran into so many interesting bugs, I’ve honestly forgotten most of them, but I do remember many of them were actually to do with extensive use of UUIDs and the interaction it had with more powerful Django ecosystem tools that did things like expose a complete JSON-API endpoint, stuff that did “query building” was generally not designed with accounting for. My favourite is having to selectively use thread locals to disable the query filtering layer for very specific internal queries that a few libraries used. I tried to get it working with context vars for future Django async support but never had the time to finish that work. The code was written with open sourcing it in mind actually. The amount of effort involved pushed me to select License Zero effort and specifically the Prosperity Public License https://prosperitylicense.com https://prosperitylicense.com (License legal TLDR is “open” but if you use it to make money you have to pay me something I agree to) I’m hoping to do a significant refactoring before I mark the 1.0 version. I have some ideas that may be vastly cleaner but really requires nailing the whole thread local / async context vars lifecycle so I’ve kind of tried to limit who might start relying on it based on how extensively tested it is.

squeaky-clean 6y ago

I lead a service that's used by about 30 airlines and did pretty much exactly the same thing. Django middleware, ULIDs, and using hypothesis for testing. I also extended the django ORM to help restrict what sort-of queries are even possible and to improve error logging for our use cases. As an extra bit of security and logging, ICAO codes everywheeeere. It's a good thing we don't sell to non ICAO airlines. I can also anecdotally confirm the statement in another user's comment about 1 tenant using 60% of everything. And it's not even a large airline! This one relatively small carrier uses more of our resources than AA, UA and a few of the other top 10 global carriers combined.