The general circles around me have already moved on to reverse proxies implemented in Rust and there is talk about reverse proxies implemented in Lean 4.
But this native Prometheus Integration with nginx, this is going to be useful to many in DevOps-ish roles out there.
I myself write custom reverse proxies, and within, export custom metrics to custom collectors but in Go instead of Rust. Now I do this for a myriad of reasons but not because Nginx was written in C?
I consider my self DevOops professionally and read this statement to mean DevOps isn't as such.
There's a lot of nuance in reverse proxies. You're off to a good start with Go as the standard library gives you a very strong and battle-tested HTTP implementation as well as a basic reverse-proxy interface to build with.
Avoiding opening a can of security-issue-worms involves knowing what you're doing and depends heavily on the environment you're operating in. Internally proxying traffic between services? A cakewalk. Translating between HTTP2 or 3 to 1.1? Forwarding origin client IP safely? Sanitizing headers (and I don't mean the in-built sanitization that Go provides)? There's a lot of little things.
Tools like Nginx and Envoy strike from the opposite direction: an extensive suite of configurable tools to reverse proxy the way you need, with relative safety.
Like you, I would almost certainly prefer writing a small reverse proxy in Go over deploying Nginx.
It's such a bad technical decision for most people. Everyone rewrites it's own gateway / reverse proxy with bugs, lacks of feature, security problems and non standard integration.
Nginx / envoy should be your default choice for most use cases.
> Nginx / envoy should be your default choice for most use cases.
Nginx was there like 15 years ago and it feels it has been stuck there with no progress ever since. No metrics, no ACME certs... I moved to Traefik and never looked back.
Yeah, I'm with you 92% that the majority shouldn't try to implement a reverse-proxy themselves. The other 8% is, some people should do such a thing because learning for them and sometimes for all of us results from stories of failure, and surprising stories of success too.
The reverse-proxies implemented in Rust (aided by Rocq of Rust) in my larger circles were written in-house for their respective platforms. These colleagues fall into the more classical definiton of engineer and "hacker". I know there are some open source reverse-proxies implemented in Rust out there but I am not yet personally familiar with them (by using and supporting them in production) and can't vouch for them.
I agree with xmcp123's comment generally. I know those guys (and some gals) use models for some static analysis of code but they don't use models to generate important code like internet-facing reverse-proxies.
I look forward to the implementations of reverse-proxies in Lean 4 which will be zero-bugs implementations, unless some macro level adjustments need to be made, and may enable the maximum possible utilization of the silicon involved even more so than Rust already does.
If a reverse-proxy implemented in CompCert C could yield some compelling result has been a recent discussion. I'm still personally getting familiar with CompCert C.
Up until the last couple of years from early-ish 2012, I used nginx for production traffic in a lot of places. I have instantiated so many K8s Ingress that were nginx and nginx has been a huge part of my professional and personal life.
Envoy being written in C++ has always given me a gut feeling to avoid Envoy. Aside from occasional SRE-ish support of Envoy (when someone else already instantiated it before I got there), I have successfully avoided it and occasionally successfully displaced Envoy with nginx. I was listening to an Oxide podcast just the other day where bcantrill commented about C++, something along the vibe of waiting for someone still somewhat early along their journey to see the light and move on to Rust.
There will never be a production Rocq of Go and if there ever is, then it wouldn't be the language we call Go today now would it. Go is for flash in the pan stuff that is only meant to.. go so far.
Prom export is also inefficient as fuck. No one serious uses it.
Edit: I wrote two, one in 2009, another in 2013 in case you wonder.
But this native Prometheus Integration with nginx, this is going to be useful to many in DevOps-ish roles out there.
I myself write custom reverse proxies, and within, export custom metrics to custom collectors but in Go instead of Rust. Now I do this for a myriad of reasons but not because Nginx was written in C?
I consider my self DevOops professionally and read this statement to mean DevOps isn't as such.
Avoiding opening a can of security-issue-worms involves knowing what you're doing and depends heavily on the environment you're operating in. Internally proxying traffic between services? A cakewalk. Translating between HTTP2 or 3 to 1.1? Forwarding origin client IP safely? Sanitizing headers (and I don't mean the in-built sanitization that Go provides)? There's a lot of little things.
Tools like Nginx and Envoy strike from the opposite direction: an extensive suite of configurable tools to reverse proxy the way you need, with relative safety.
Like you, I would almost certainly prefer writing a small reverse proxy in Go over deploying Nginx.
Nginx / envoy should be your default choice for most use cases.
Just because you can doesn’t mean you should. There is a lot to be said for battle tested.
Nginx was there like 15 years ago and it feels it has been stuck there with no progress ever since. No metrics, no ACME certs... I moved to Traefik and never looked back.
https://nginx.org/en/docs/http/ngx_http_acme_module.html
https://github.com/nginx/nginx-prometheus-exporter
The reverse-proxies implemented in Rust (aided by Rocq of Rust) in my larger circles were written in-house for their respective platforms. These colleagues fall into the more classical definiton of engineer and "hacker". I know there are some open source reverse-proxies implemented in Rust out there but I am not yet personally familiar with them (by using and supporting them in production) and can't vouch for them.
I agree with xmcp123's comment generally. I know those guys (and some gals) use models for some static analysis of code but they don't use models to generate important code like internet-facing reverse-proxies.
I look forward to the implementations of reverse-proxies in Lean 4 which will be zero-bugs implementations, unless some macro level adjustments need to be made, and may enable the maximum possible utilization of the silicon involved even more so than Rust already does.
If a reverse-proxy implemented in CompCert C could yield some compelling result has been a recent discussion. I'm still personally getting familiar with CompCert C.
Up until the last couple of years from early-ish 2012, I used nginx for production traffic in a lot of places. I have instantiated so many K8s Ingress that were nginx and nginx has been a huge part of my professional and personal life.
Envoy being written in C++ has always given me a gut feeling to avoid Envoy. Aside from occasional SRE-ish support of Envoy (when someone else already instantiated it before I got there), I have successfully avoided it and occasionally successfully displaced Envoy with nginx. I was listening to an Oxide podcast just the other day where bcantrill commented about C++, something along the vibe of waiting for someone still somewhat early along their journey to see the light and move on to Rust.
There will never be a production Rocq of Go and if there ever is, then it wouldn't be the language we call Go today now would it. Go is for flash in the pan stuff that is only meant to.. go so far.