Will be interested to see why I would use this instead of Envoy or similar FOSS. One obvious thing would be giving the operational work to Cloudflare instead of doing it myself, but beyond that it reads like "we built an internal thing in Rust."
Oxy is Cloudflare's Rust-based next generation proxy framework
21–30 of 62 posts
Re: Oxy is Cloudflare's Rust-based next generation proxy framework
#22> Oxy heavily relies on open-source dependencies, with hyper and tokio being the backbone of the framework It seems almost every single production async framework uses tokio instead of async-std. Has tokio won? Is there a reason in 2023 not to use tokio as the async base?
Recent downloads on crates.io (like npm for Rust)
- Tokio 12.1M
- Async-std 1.6M
It’s an order of magnitude difference.
Re: Oxy is Cloudflare's Rust-based next generation proxy framework
#23Earlier quoted context omitted.
That's basically what all technical blogs from corporations does. I suppose they imagine we'd learn something it. I concur with the other commentator, bit disappointing it's not OSS, guess they are afraid of helping the competition. I did expect a "and you can give it a try here" section in the end.
We're not afraid of helping the competition. Example: we open sourced the entire runtime for Cloudflare Workers! https://github.com/cloudflare/workerd Open sourcing something has a cost and we mostly only open source things like stand-alone libraries. We also mostly open source things that are fairly mature because it's hard to manage software that's rapidly changing internally and handle PRs from outside.
You did mention on your Pingora post months ago that that would be open-sourced eventually though. Is that still the case? Is Oxy entirely separate from those plans?
Re: Oxy is Cloudflare's Rust-based next generation proxy framework
#24While it is interesting that they achieved a technical feat, is there any reason for this article to be here? It teaches us nothing apart from the fact that Cloudflare did a thing.
That's basically what all technical blogs from corporations does. I suppose they imagine we'd learn something it. I concur with the other commentator, bit disappointing it's not OSS, guess they are afraid of helping the competition. I did expect a "and you can give it a try here" section in the end.
What kind of corporate but tech stuff do people find interesting? Curious, im looking to write more to practice but idk exactly what kind of stuff people are interested or what level of technical information they want too. Interested in anyones answers
Re: Oxy is Cloudflare's Rust-based next generation proxy framework
#25Will be interested to see why I would use this instead of Envoy or similar FOSS. One obvious thing would be giving the operational work to Cloudflare instead of doing it myself, but beyond that it reads like "we built an internal thing in Rust."
I mean... You wouldn't, unless you started working at Cloudflare. It seems to be an internal proprietary framework.
Re: Oxy is Cloudflare's Rust-based next generation proxy framework
#26While it is interesting that they achieved a technical feat, is there any reason for this article to be here? It teaches us nothing apart from the fact that Cloudflare did a thing.
It provides "validation" (as the kids say) to Rust, Tokio, and Hyper. Whether they need additional validation at this point is debatable though.
Re: Oxy is Cloudflare's Rust-based next generation proxy framework
#27While it is interesting that they achieved a technical feat, is there any reason for this article to be here? It teaches us nothing apart from the fact that Cloudflare did a thing.
Because of one word, and I think you know which it is.
Re: Oxy is Cloudflare's Rust-based next generation proxy framework
#28It’s not OSS :( I figured with this type of blog post the finale would be, and everyone can try it out at… Hopefully they do release it OSS eventually.
[flagged]
Re: Oxy is Cloudflare's Rust-based next generation proxy framework
#29Re: Oxy is Cloudflare's Rust-based next generation proxy framework
#30> Oxy heavily relies on open-source dependencies, with hyper and tokio being the backbone of the framework It seems almost every single production async framework uses tokio instead of async-std. Has tokio won? Is there a reason in 2023 not to use tokio as the async base?
Deno has periodically had open github issues or ideas where there's possible paths but tied to Tokio & they seem to want to leave the door open for now. Just one tiny data point but I find it interesting.