Reverse proxies are great to handle logging, tracing, and authentication on applications you don't own or which you cannot modify the source code to make them do what you need.
A reverse proxy is nothing more than an HTTP server that handles a request and makes the request to a backend server. When doing so, it may add some headers, log data about the request or stop the request if authentication fails.
On the other hand, Gin is a very popular and great web-based application framework. It helps to build powerful REST API quickly, it has a lot of useful features and it's very fast since it uses httprouter under the hood. The idea is to handle HTTP requests with Gin and then proxy the request to the backend using the built-in reverse proxy.
The ReverseProxy struct contains a Director field. A director a function where you tell the reverse proxy what to do with the incoming request. It is where you may change the host, maybe add some headers, or even check the authentication.
At work I often have to switch from a repo to another, making some change here and not there, starting a new branch on repo A and then, fixing an issue on repo B. Ideally, a big fat monorepo should help me to deal with the ~40 apps and libs I work on. But monorepos have drawbacks when you're not Facebook or Google. By the time, they become heavier and soon a simple git status takes more than 2 seconds.
Instead of a monorepo I have built a few script helping me to deal with all those repos. One of them helps me knowing the status of each repository, just to know where I am and what I was doing before being interrupted.
So here we are… building a Go script to parse a git repository status.
Let's face it, your company is not a Big Tech company. You, the reader, are probably not working for Google, Microsoft or Facebook and it's ok. A lot of companies not so big have a huge impact and very high tech challenges.
But not being a big tech company also means you probably won't be good at what you're doing if you act the same way Facebook or Amazon does. This is true for tech choices and system architecture. This is also true for recruiting software engineers.
In my journey looking for the best way to manage my to-do list, I recently tried to create a Trello board where to put all the new tasks added to my personal backlog. My choice of using Trello was based on several needs:
Being able to follow up all the in progress tasks
Being able to order tasks by priorities
Since Trello is very flexible, I thought that I could create one card by item and three columns: to-do, work in progress, and done. But then, I started to have lots of cards in my to-do column and thought I needed to re-order all the cards to be able to quickly see which have a high priority and which can wait.
I first tried to create an intermediate to-do column called “today” where to put the item I needed to be done by the end of the day. I quickly found out I still had to deal with all the other cards in the “to-do” column which needed review each morning. Thus, I moved once again and created three to-do column :
For a while, this system seems perfect. Each time I had completed a task, I was able to see which one will be the next to focus on by looking at the priority #1 column. I had a clear view of what I really needed to do at any time. Every week or so, I reviewed my to-do lists in order to move cards from lower priority to higher. Or, at the contrary, I lowered the priority of some tasks considering they were supposed to be priority #1 but I hadn't time to work on it and the world didn't stop.