31 ms·

To clarify, are you saying that: 1. There are already good reverse proxy libraries in C#? 2. There are already good reverse proxy libraries in other languages

To clarify, are you saying that: 1. There are already good reverse proxy libraries in C#? 2. There are already good reverse proxy libraries in other languages? 3. There are already good reverse proxy applications? If it's #1, then yeah, it would be nice if the ReadMe explained why YARP is different. To be fair, they're at least consolidating a bunch of efforts within Microsoft: > We found a bunch of internal teams at Microsoft who were either building a reverse proxy for their service or had been asking about APIs and tech for building one, so we decided to get them all together to work on a common solution, this project. If it's #2, then what do C# developers do? Having to build your proxy in another language isn't a deal-breaker, but there are advantages to keeping your project/team/company on a single language. (And Microsoft does contribute to Envoy [1][2].) If it's #3, that only works up to a point. My old team used Nginx, which was perfect in the beginning. But over time we needed to customize things in ways that were difficult to do within Nginx's architecture (either in Lua or in C), leading to hackier and hackier solutions. Using a proxy library to build exactly what you need can make things much simpler. [1] https://blog.envoyproxy.io/general-availability-of-envoy-on-windows-267e4544994a https://blog.envoyproxy.io/general-availability-of-envoy-on-... [2] https://techcrunch.com/2020/08/05/microsoft-launches-open-service-mesh/ https://techcrunch.com/2020/08/05/microsoft-launches-open-se...

bob1029 5y ago
> But over time we needed to customize things in ways that were difficult to do within Nginx's architecture (either in Lua or in C), leading to hackier and hackier solutions. Using a proxy library to build exactly what you need can make things much simpler. This is the central argument for me regarding why we don't "just use nginx". We actually do use it for some corporate websites, but not for our main product. There is a ton of power hiding here... With a well-supported first-party RP framework, how long would it take for a determined developer to replicate the most important bits of the nginx feature set? Imagine being able to throw a blazor dashboard on top of this stuff. Wiring up real-time events/metrics would be super trivial if you are even remotely interested in learning how the DI system operates. Mix in a little bit of SQLite and you could have something I may argue provides a better UX than what nginx offers today.
kristaps 5y ago
Can you share more specifics on what you needed to customize that went beyond nginx's capabilities?
- cakoose 5y ago
  This was 5+ years ago so I'm a little hazy on the details. A lot of it was just plugging into our infrastructure for config, service discovery, rate limiting, logging, etc. - Logging the exact metrics we wanted to our metrics service. (We wrote a bunch of Lua code to do this.) - Loading the set of backend services from Zookeeper. (We had a sidecar process that would periodically sync from Zookeeper to a config file, then call `nginx reload`.) - Routing requests to different datacenters based on where the user's data was homed. (We had Go libraries to do this, and it would have been nice to be able to just call into that. I think we ended up putting this functionality in the sidecar.) - Changing the way we streamed a response based on an HTTP header from the application. (We ended up writing a C module for this.) - Changing the backend selection algorithm from "least connections" to "best of 3 random choices". Nginx added support for this in 2018, apparently. There were ton of things we solved with Lua, which wasn't ideal. Since that's the only Lua in our codebase, everyone who touches it has to make a mental switch to remember all the weird edge cases (as you do with any language), plus 1-based array indexes, plus no static types. Plus, any Lua or C you write has be contorted to fit Nginx's multi-stage request/response architecture. If you're writing a plugin that is meant to play nice with other plugins, then the contortions may be worth it. But for us, a proxy library would have given us the freedom to write code that was simpler and easier to understand. The team moved to Envoy after I left: https://dropbox.tech/infrastructure/how-we-migrated-dropbox-from-nginx-to-envoy https://dropbox.tech/infrastructure/how-we-migrated-dropbox-...
  - kristaps 5y ago
    Your application does indeed sound like it's beyond OTS solutions, thanks for sharing!
zamalek 5y ago
> But over time we needed to customize things in ways that were difficult to do within Nginx's architecture (either in Lua or in C), Yup. Eventually a configuration language becomes a shitty programming language, so why don't we just use a programming language?
- idubrov 5y ago
  It's the configuration complexity clock! http://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html http://mikehadlow.blogspot.com/2012/05/configuration-complex...

bob1029 5y ago

> But over time we needed to customize things in ways that were difficult to do within Nginx's architecture (either in Lua or in C), leading to hackier and hackier solutions. Using a proxy library to build exactly what you need can make things much simpler. This is the central argument for me regarding why we don't "just use nginx". We actually do use it for some corporate websites, but not for our main product. There is a ton of power hiding here... With a well-supported first-party RP framework, how long would it take for a determined developer to replicate the most important bits of the nginx feature set? Imagine being able to throw a blazor dashboard on top of this stuff. Wiring up real-time events/metrics would be super trivial if you are even remotely interested in learning how the DI system operates. Mix in a little bit of SQLite and you could have something I may argue provides a better UX than what nginx offers today.

kristaps 5y ago

Can you share more specifics on what you needed to customize that went beyond nginx's capabilities?

cakoose 5y ago
This was 5+ years ago so I'm a little hazy on the details. A lot of it was just plugging into our infrastructure for config, service discovery, rate limiting, logging, etc. - Logging the exact metrics we wanted to our metrics service. (We wrote a bunch of Lua code to do this.) - Loading the set of backend services from Zookeeper. (We had a sidecar process that would periodically sync from Zookeeper to a config file, then call `nginx reload`.) - Routing requests to different datacenters based on where the user's data was homed. (We had Go libraries to do this, and it would have been nice to be able to just call into that. I think we ended up putting this functionality in the sidecar.) - Changing the way we streamed a response based on an HTTP header from the application. (We ended up writing a C module for this.) - Changing the backend selection algorithm from "least connections" to "best of 3 random choices". Nginx added support for this in 2018, apparently. There were ton of things we solved with Lua, which wasn't ideal. Since that's the only Lua in our codebase, everyone who touches it has to make a mental switch to remember all the weird edge cases (as you do with any language), plus 1-based array indexes, plus no static types. Plus, any Lua or C you write has be contorted to fit Nginx's multi-stage request/response architecture. If you're writing a plugin that is meant to play nice with other plugins, then the contortions may be worth it. But for us, a proxy library would have given us the freedom to write code that was simpler and easier to understand. The team moved to Envoy after I left: https://dropbox.tech/infrastructure/how-we-migrated-dropbox-from-nginx-to-envoy https://dropbox.tech/infrastructure/how-we-migrated-dropbox-...
- kristaps 5y ago
  Your application does indeed sound like it's beyond OTS solutions, thanks for sharing!

zamalek 5y ago

> But over time we needed to customize things in ways that were difficult to do within Nginx's architecture (either in Lua or in C), Yup. Eventually a configuration language becomes a shitty programming language, so why don't we just use a programming language?

idubrov 5y ago
It's the configuration complexity clock! http://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html http://mikehadlow.blogspot.com/2012/05/configuration-complex...