11 ms·
Sometimes it feels like Microsoft and/or C#-enjoyers just want to re-implement everything that already exists. While having many implementations to choose from
by oneplane 5y ago
Sometimes it feels like Microsoft and/or C#-enjoyers just want to re-implement everything that already exists. While having many implementations to choose from if you need to select a solution to an outstanding problem is great, it makes me wonder why re-implementing something with no discernible benefit keeps eating time/resources all over the place.
In similar cases of implementing reverse proxies in C, C++, Rust, Go and Java, there were generally benefits in various shapes and sizes like different security models, performance vs. capability trade-offs and integrated vs. specialised solutions. In this case, it just seems to be a "we don't want the stuff we didn't build ourselves" which is a shame considering the benefits of pooling resources on existing implementations would have.
- 123pie123 5y ago>Sometimes it feels like Microsoft and/or C#-enjoyers just want to re-implement everything that already exists It sometimes feels to me, like a huge percentage of developers reinvent the wheel
- civilized 5y agoThere are thousands of Java accounting apps and thousands of shitty medical billing websites. I think most devs are definitely reinventing the wheel for the ten thousandth time
- dudeman13 5y ago>There are thousands of Java accounting apps There is already a solution that lets us not reinvent this particular wheel. It's called Excel. I hate using it.
- dqv 5y agoAnd for good reasons. I think there is an almost ignorant annoyance with devs who reinvent, but a lot of times they’re reinventing a punctured wheel or the wheel is for a bulldozer and they need one for a minivan. I had this exact experience: “why should I reinvent the wheel?” Oh this solution doesn’t let you apply partial payments or apply one payment to multiple invoices. This one doesn’t create account statements. This one can’t fax invoices. This one only supports Stripe (and has its own undocumented billing API because who would use anything other than Stripe?). This one has a weird XML definition system for subscription pricing which makes it difficult if not impossible to handle negotiated rates on a per-account basis. Not to mention having to teach billing people how to write the weird XML. This one won’t prorate invoices. This one is a cloud service that costs $100+ a month and is liable to be unavailable when I really need it! They all have weird features that I will never use. Ok, we’ll go with this imperfect one and make some changes. But where’s the entry point? How does weird framework in weird language even work? What are the conventions? How is the original developer differing from those conventions? And then you come to the realization that the wheel gets reinvented because the existing wheels were made with specific business logic in mind. While this can often be generalized for a particular industry or set of use cases, it often does not and can not cover all use cases. The wheel is reinvented. (Not so fast with the XKCD comic about new standards. We’re not imposing standards on others, we just need our software to work for us.) Sometimes the wheel doesn’t need to be reinvented. Some help desk software I wanted to use needed some slight tweaks. The entry points were obvious and the development environment was easy to setup. I made the tweaks and was good to go.
- amelius 5y agoAnd how would we cope with this in, say, 100 years, when the list of required functionalities is much larger, and a new language comes along?
- pjmlp 5y agoAh, that is why cars still use chariot wheels.
- bob1029 5y ago> re-implementing something with no discernible benefit keeps eating time/resources all over the place. > is a shame considering the benefits of pooling resources on existing implementations would have. What exactly would you prefer these developers spend their time on instead of this work? There are a lot of benefits to being able to integrate your own reverse proxy directly into your software stack. C# developers enjoy these as much as anyone else would.
- qbasic_forever 5y ago
- jeeeb 5y ago> There are a lot of benefits to being able to integrate your own reverse proxy directly into your software stack. C# developers enjoy these as much as anyone else would. I take this at face value but it would be nice to know what the benefits are vs nginx and other off the shelf solutions. The readme explains the benefit for Microsoft but not how it stacks against off the self solutions.
- akshayshah 5y ago> The readme explains the benefit for Microsoft but not how it stacks against off the self solutions. Totally agree. Seems to me that the main benefit is that it's easy to extend in .NET, vs. C/C++/Lua/WASM.
- bob1029 5y ago> it would be nice to know what the benefits are vs nginx and other off the shelf solutions. Biggest difference in my view is being able to make synchronous blocking calls directly into any arbitrary business code in order to determine the fate of a request. This can include rule/policy engines as well as auditing & tracing frameworks.
- andreypopp 5y agoLua in nginx can you get very far in my experience.
- qbasic_forever 5y agoIt's only in the last 5 years that .NET was open sourced and made available officially for Linux systems. Up until then most C# use was strictly on Windows, and OSS especially for Windows server side stuff (IIS, SQL server, etc.) was (and still is) pretty rare. I've seen windows server places (Microsoft) implement everything from redis, memcached, queue systems, prometheus, lucene, DNS servers, to reverse proxies, etc. entirely from scratch out of necessity. Years and years of man hours going into building and supporting something that would be a simple debian package install on Linux. I have no insight into it but my gut tells me windows server exclusive shops are probably dwindling and have long ago realized they needed to start moving to Linux, especially now that .NET is officially supported there. I think the days of reinventing everything in C#/.NET/windows are coming to an end fast.
- oaiey 5y agoAnd that is not a gut prediction but history. 15 years ago the default was Windows, .NET and SQL Server. 5 years ago it is Linux in the cloud, .NET and PostgreSQL.
- rswail 5y agoC#/.NET/CLR are competing against Java/JRE/JVM. So reinventing "everything" in a Windows Server environment is slowly coming to an end, with Windows server becoming a hypervisor for VMs/containers and a runtime for .NET/CLR. The economics of getting all of the FOSS infrastructure tooling in a "Windows native" form is being beaten by just running them in containers/VMs on whatever hypervisor is available. In the same way, Linux is becoming a hypervisor for containers and the various container runtimes.
- pjmlp 5y agoLinux is being replaced by type 1 hypervisors, no need for Linux to run a container runtime.
- cakoose 5y agoTo 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
- assttoasstmgr 5y agoWould your reaction have been different if, instead of Microsoft, this article was submitted by some random person entitled "Show HN: I built a reverse proxy in C#"? By your logic, the world should be operating on a single OS, with a single web browser, paired with a single web server, because why re-implement something that already exists?
- pydry 5y agoPretty much every "I built a thing" post is met with the same response. MS isnt special. I think pretty much every open source project that wants to be taken seriously needs to compare itself with its competitors.
- assttoasstmgr 5y agoFrom what I can tell they built a tool for themselves to use internally, and open-sourced it. I don't think they were looking for approval or to be taken seriously. Similarly, Igor built nginx to solve a particular problem, and I think it was a few years before it went open-source. I can't imagine most OSS developers have delusions of grandeur.
- throwuxiytayq 5y agoGiven that pretty much all of the recent Microsoft's open-source projects under the .NET umbrella, including ASP.NET Core, have been a resounding success in terms of communiry adoption, I don't think they're very shy about comparisons. I expect some of the comments under this post to age very badly.
- pjmlp 5y agoNope, if it is an HN hyped language it gets all the love of the day, Ruby, Clojure, Rust,....
- pydry 5y agoRust rewrites get a bit more love by default because it's implicitly assumed it'll be fast and bug free compared to alternatives.
- AlphaSite 5y agoIt competes with this: https://spring.io/projects/spring-cloud-gateway https://spring.io/projects/spring-cloud-gateway AFAICT.
- mrkurt 5y agoThere aren't a lot of good proxy development frameworks. There are decent lower level libraries, and proxy servers with limited scriptability. I've spent the last 4 years at Fly.io wishing for a nice, full featured, proxy framework. This looks pretty darn good to me.
- melony 5y agoThe Go standard library?
- sopium 5y agoI find hyper quite nice to work with to build reverse proxies, mostly thanks to the HTTP client and server having common types for request, response, headers and body streams etc. I agree that it is only a decent lower level library rather than a full featured proxy framework though.
- js4ever 5y agoA Ruby on rails shop like fly.io would use .net?
- square_usual 5y agoWait, fly.io is a Rails shop? (At any rate, they employ Chris McCord, the creator of Phoenix, and have spent considerable resources pushing Phoenix. So it's clear that they aren't beholden to any one language or ecosystem.)
- oaiey 5y agoHe explains the use case why you need a RP framework in your language of choice not his desire at fly.io (I guess :))
- mrkurt 5y agoI think we have more Rust and Go than Ruby at this point. Probably slightly less Elixir. For better or worse we're not really fixated on one language.
- codeulike 5y agoSeems like the fact that its built in C# isn't really the main point. The main point it that it runs on asp.net infrastructure
- deleted 5y ago[deleted]
- deleted 5y ago[deleted]