Hey all,
We've been picking up momentum in the TO Perl -> Go rewrite recently,
which has gotten me thinking of ways to reduce the risk of possible
regressions in the rewritten APIs. I'd like to propose that we
implement a sort of "routing blacklist" for the TO API routes.
At a high level, this blacklist would be a simple JSON config file like this:
{
"perlRoutes": [
{"method": "GET", "path": "/api/1.1/foos"},
{"method": "POST", "path": "/api/1.1/foos"}
],
"disabledRoutes": [
{"method": "GET", "path": "/api/1.1/foos"},
{"method": "POST", "path": "/api/1.1/foos"}
]
}
APIs in "perlRoutes" would be explicitly routed to the Perl, even if
the Go route exists and could handle the request. The primary use case
for this feature would be to deploy an upgraded version of TO-Go with
rewritten APIs without having TO-Go handle the requests yet.
Post-upgrade, you could remove a rewritten route from the blacklist on
a single TO instance, validate it for some period of time, then roll
out the rewritten API to other TO instances by removing the API from
their blacklists.
APIs in "disabledRoutes" would be explicitly disabled. The use cases
for this field would include:
- disabling endpoints that are part of an incomplete feature and don't
really make sense to use on their own yet
- disabling endpoints that have known, serious issues that should be
disabled immediately
This would make it easier to plug holes in TO without having to
rebuild and redeploy.
Ideally, this config file would be SIGHUP-able so that it can be
reconfigured without having to restart TO. Also, there should be a
hardcoded list of "Perl-routable" routes within TO-Go, so that you
can't just depend on Perl forever if you wanted. I would propose that
newly rewritten routes be added to this hardcoded list in TO-Go. Then
after being in one release as "Perl-routable", they would become
"non-Perl-routable" in the following release.
IMO we could've used something like this since the beginning of the TO
Perl -> Go rewrite effort, but we still do have a decent amount of
routes left that this could be useful for.
Please let me know what you think. If we're generally +1 on this idea,
I'll throw together a blueprint with more details, then maybe I can
convince my boss to let me work on it ;)
- Rawlin
