Story #9053

Updated by Tom Clegg over 2 years ago

h2. Background

We want to replace our Rails server with a Go server. However:
* Porting the entire code base to Go, and cutting over everything at once, seems unlikely to go smoothly.
* In the time it takes to port, the Rails functionality will change. Keeping them in sync will be challenging.
* Porting the functionality and the corresponding tests at once is likely to result in unnoticed errors and omissions.

h2. Development Proposed approach

The first version of the Go service is just an HTTP proxy: it forwards each request to a configured upstream Rails API server. Nginx configs in the install docs (and existing deployments) are updated to send API requests to this new server.

Next, port _some_ functional/integration tests from the Rails server code base to the Go code base. These tests will pass because Go server is already proxying the relevant requests to the Rails server. (Mocking won't be portable, though!)

Each test that has been ported to Go can be skipped in the Rails code base.

When enough Rails tests are skipped to remove an API from Rails _without making the remaining tests fail_, that API can be ported to Go. The relevant tests are already in place in the Go code base, so they should be a reasonable way to confirm that the new Go port is correct.

Repeat until all tests are ported to Go, and they pass even with the proxy-to-Rails feature removed.

h2. Caveats / TBD

Rails tests are fast (at least faster than Workbench tests, for example) because they use transaction rollback to reset database state. This option won't be available when tests run in a different (Go) process. Practically, this means the Go tests will need to use the "database reset" API, and they will run slowly.
* Perhaps we can start by implementing "database reset" in Go? It will have direct access to the Postgres database, and it could take a snapshot of the database at startup instead of reading the Rails YAML fixtures.
* Is there a better way around this?

Back