Firstly, you don't have to be rude. I won't fall for this bait.
Secondly, if you are tied to writing one configuration file, I understand, after all you have a free choice. For me, the separation of logic is a positive aspect, because I don't have to think and search for entries about the specific server I'm proxying to. JSONs used here are overcomplicated I see. And the difficulty of mounting configuration files from ConfigMap with one file or two is practically the same - yet with this software you store two files in ConfigMap. I understood from your post that you are a HAProxy fanatic and I won't bother you in any way.
We had a problem with a solution from a large international supplier. While doing an external audit (pentesting), we came across vulnerabilities and the possibility of ‘breaking’ the system as a whole (apart from the fact that natively the system did not support service-mesh, which was required by the client...). So, to mitigate the open vulnerabilities and add service-mesh (sort of), we used Apache (httpd), but writing the configuration and figuring out how to patch it well was driving me crazy. That's why this solution was created, if I'm honest it took me a week to write it, which is about the time I had to solve the problem described earlier. I got the green light from my superiors for something of my own and that's how this project came about. Plus the fact that I wanted to see how rusty my Python was :)
Ok, HAProxy is a potential solution, but according to the description I posted, the idea behind this project is to reduce the writing of configuration files. Instead of writing an elaborate conf, just provide two JSONs to achieve the same thing. And yes I am aware of the fact that solutions like Apache, HaProxy and NginX are more popular and preferred for large solutions. I do not want to create yet another miracle product in well researched matter.
But I am grateful for the feedback :)
I mostly agree with you, I learned java at university but dropped it because python (mostly scripts) are very useful for DevOps / SysAdmin work. I definitely agree that writing proxies in Python is not the best idea, but it is the language I know best. And yes, it's not a high-level goal, but as I replied to someone earlier in this comments section. I don't want to make a career out of this, I just wrote a tool that was needed in my organisation and brought it here because I thought it might be useful to someone. Thank you for the extended comment.
P.S: Yes I am looking for some high-level project to participate in or just help with the knowledge I have.
To be honest, I don't want to make a career out of it and I didn't plan it for this project, I just needed a tool like this, so I wrote it because I was tired of configuring Apache :) I thought it might be useful to someone else, so I published it here. Thanks, I just had to say it
Request Time: The average request time in all tests is about the same, ranging from 0.006 to 0.007 seconds. Max request time does increase with more requests; it peaks for the most substantial test of 100,000 requests at 0.136 seconds, which does show that some requests take much longer.
Requests per Second: The number of requests per second is highest in the smaller tests, around 143 RPS for the 10 requests, whereas for 100,000 requests it goes down to about 122 RPS. A probable conclusion in this case could be that while increasing the number of requests, some little slowdown starts to develop in the system.
Percentiles: The median, which usually stands at approximately 0.0035 seconds, essentially means half of the requests are done in under that time. The far higher values of the 90th and 99th percentiles just prove that while most of the requests may be fast, the others take considerably longer.
In general, it performs quite well under a reasonable load but biffs a bit if the number of requests is increased.
Yes, I agree that applications themselves should handle requests that are not correct for them. I in my experience (maybe not so great :)) have encountered several times products even of large corporations that goofed up with problematic requests and/or payloads in that request. But yes I agree with you,it is adding an extra layer and complexity to the deployment, but sometimes it is a very convenient tool - for example as I mentioned before if you don't want to use off-the-shelf products like apache or nginx. Which should do the job and sift out the bad from the good.