This reverse proxy project will expand my professional skills and knowledge in a number of important ways. Namely, I’ll deepen my experience in key areas such as safe concurrency, performance tuning, network protocols, observability, and configuration management. Building upon the foundation I’ve gained through past projects and coursework, I’ll use this project to delve into some of the ways production systems handle traffic at scale.
This project is important to me because I’m in my final semester in the program and will be applying to jobs this semester. Specifically, I’m planning to apply to jobs in Japan, so I’ve been familiarizing myself with the job market there and connecting those findings to my own preferences and skills. Although I’ll need to continue to deepen my understanding of what kinds of opportunities are available, placing my focus between networking and web backend seems to be a good balance between realistic job availability and my interests in Rust and systems programming.
unwrap, expect, and unsafe (and not producing any other warnings)X-Forwarded-For, Connection)tracing crate)The main risks fall under the category of lack of familiarity with the subject/domain. While I’ve worked with HTTP requests in various contexts in some of my previous projects, the requests in those projects were simpler and more focused on application logic. Conversely, I’ve also done projects involving network protocols and packet parsing, which is relevant, but lower level than what I’ll need to do here. Consequently, I may be misjudging the amount of time and effort required to understand and implement the features and goals I’ve planned out for the semester.
The main mitigation strategy that I plan to use is flexibility on what a complete project is. The choice of a reverse proxy itself is one of the key elements of this strategy. Specifically, I’ll have something that “works” in only a few weeks, and most of the goals can be added or removed without making the project feel incomplete. This is in contrast with other potential project ideas where most goals depend on previous ones and a complete product is only reached at the end. By having a flexible attitude and a project that lends itself to flexibility, I’ll be able to mitigate the scope risks that exist due to my unfamiliarity with the subject.
Also, the technical environment of Rust, the tokio runtime, and commonly used crates (libraries) such as hyper, rustls, and tracing is relatively close to that of projects I’ve done in the past, even though what I’ll be implementing is different. This will allow me to focus on understanding the reverse proxy implementation and developing my concurrent programming skills.
The main evaluation criteria for the project are the goals listed above. I will know the project is complete when everything listed under “core goals” is implemented and tested. However, as I mentioned in the mitigation strategy, I will still consider the project a success even if I have to adjust the goals slightly.
To be a bit more concrete, the main way I plan to consider a goal complete is through testing. For example, I will have unit and integration tests confirming that modules’ internal logic works as defined, issues like malformed requests and unhealthy backends are handled, and the overall project continues to work as expected as load increases.
I’m taking this approach because I consider this project different from one that’s focused on application logic and requires cloud deployment and full-stack usability as a core part of being considered complete. Instead, I want to take a more systems-oriented approach and place the focus on conceptual understanding, code quality, and performance.