Skip to content

Backend converted from Python to Go

No due date 40% complete

The Desert Atlas backend was written hastily in Python. Over time I would like to move it to Go. In the interim, there will be both a Python and a Go server. (Technical details on this below). Since this part is not hasty, we'll improve code quality by decoupling concerns, and adding unit tests.

Reasons for Go over Python

In no particular order

  • Possibly …

The Desert Atlas backend was written hastily in Python. Over time I would like to move it to Go. In the interim, there will be both a Python and a Go server. (Technical details on this below). Since this part is not hasty, we'll improve code quality by decoupling concerns, and adding unit tests.

Reasons for Go over Python

In no particular order

  • Possibly faster startup
  • Smaller app spk
  • Leverage concurrency to more elegantly handle downloads
  • Static typing is good
  • Possibly share code some day with front end; I'd like to move it to TinyGo/WASM

Technicals

This is an inherently technical milestone. It's also going to be a lot of shared concepts between all of its issues. So I will get into some of the technical aspects here. The issues under this milestone should invite readers to refer here for these details.

Before this milestone begins, only the Python server sits behind Nginx. After this milestone is complete, only the Go server sits behind nginx. In between, we will have a mixture of the two. There will be two ways that this mixture will be configured:

Side-by-side: Nginx will send some requests to the Python server and some requests to the Go server. It will determine which server to send to based on the root of the URL's path. If there's an endpoint that we've reimplemented entirely in Go, we move that endpoint's path accordingly (in Nginx and the frontend code that calls it).
Internal: For some endpoints, we will only reimplement part of its functionality at a time in Go. For such endpoints, Nginx will send requests to the Python server, which will in turn make requests to the Go server for that particular functionality. The Go server will have certain internal-only endpoints for this purpose during the transition phase.

The reason we will have some internal endpoints is that a lot of the behavior in the Python server is tightly coupled, for some endpoints more than others. For some of the more complex endpoints, it would be easier to implement small parts of it in Go at a time. A good example would be moving the interface to a certain database table. It's a good self-contained bit of behavior, and Python can cleanly access it instead of doing its own direct db calls. This process also gives us the benefit of decoupling it as we go, making the code more maintainable.

Loading