Blackout Testing in FlexMeasures API
This article was originally posted at FlexMeasures
What is “Blackout testing”? A tool to provide stable API development to your users in the long-term. By prescribed “shock therapy” 🙂
FlexMeasures is already a few years in development, and therefore we are running into issues of longer-term support while innovation is still ongoing. As we have refactored the data model, we also need to move forward with the API and stop supporting older versions.
For us as a team, this was an opportunity to adopt proper customer/user support, learning from other professionals who support APIs for the long run. This benefits hosters of FlexMeasures as well as our users.
Often, API endpoints change or are put out of use (becoming legacy part of the software, eventually not served anymore). However, users currently rely on them. And they hate upgrading. They might not all jump to upgrading their own systems, even if you suggest in time that they should. Why act now, right? Maybe tomorrow! This is a major problem for SaaS providers, who need to innovate and move on.
Here is the usual how it fits into your process: First comes deprecation (API is now legacy code), then sunset (API stops being served). Both of these are pre-announced with clear dates. Both also give the using systems automated signals: HTTP headers label the stage implicitly (deprecation or sunset), and HTTP status codes do that explicitly (e.g. moving from 200 OK to 410 Gone and finally 404 NotFound).
In short, a blackout test would temporarily simulate the removal (return 410 instead of 200) for a pre-announced short while, maybe an hour.
That should really get everyone’s attention 🙂
If you are hosting FlexMeasures, then from version 0.14 on, a blackout test can be activated by changing a simple setting (FLEXMEASURES_API_SUNSET_ACTIVE).
If you are a user connected to a FlexMeasures server, this simply means you will be served better. Fewer surprises, still innovation!