Over the last year, we have begun the process of migrating many Nature journals to our new platform. Because journals on the new platform also come with a significant redesign, we were required to run an opt-in beta program to trial the new design and gather feedback.
The beta program had many requirements:
- Opted out users should see the old version of the site on the legacy platform
- Opted in users should see the new version of the site on the new platform
- Old-style URLs should redirect to new-style URLs for opted-in users
- New-style URLs should redirect to old-style URLs for opted-out users
- We should be able to run a private beta for internal users
- We should be able to automatically opt-in a percentage of users as the beta matures
It quickly became apparent that we’d need a layer in front of both platforms; with requests being routed based on whether the user is allowed to see the beta, and whether they’ve opted in.
This allowed us to inject a very small proxy layer (Thundermole) in front of both platforms, and reuse all of the existing application logic in a Ruby-based API. The application flow looks like this:
- A user request comes into Thundermole
- Thundermole calls our beta program API with the user request’s headers and path
- The API responds with a proxy target depending on the user’s opt-in status
- Thundermole routes the original user request to the specified target
Thundermole’s role in our stack became very clear and simple: Proxy user requests to different applications based on an API response.
We’re big fans of open-source, and as soon as Thundermole no longer needed to hold any business logic we decided that it belongs in the public domain. You can browse the source code and use Thundermole in your own stack here:
For when you want to write your own API, we’ve outlined a Thundermole API Specification.
As with all of our open-source projects, we love contributions and feedback. It’d also be pretty cool to say you wrote code that sits in front of Nature journals 😉