With the trending news that nginx has been acquired by F5 (https://news.ycombinator.com/item?id=19362326) it sparked the natural discussion of nginx alternatives despite F5 committing to the continued open source project development.
That got me wondering what it would take to utilize Cowboy standalone as a replacement for nginx for people who aren’t using Erlang/Elixir? Are there guides out there for it? Would it be viable?
If so it seems like this would be a very good opportunity to position Cowboy as an alternative, which would realistically generate more investment and development in the project…and as a likely byproduct create more interest in the BEAM ecosystem as a whole to a wider audience.
If Cowboy is a viable replacement, this would seem to be a rare “preparation meets opportunity” moment.
I don’t see how Cowboy can be compared to nginx. nginx is (mainly) a load balancer in the sense it sends load (requests) to different machines. cowboy is a library that receives requests from clients specific to languages using BEAM.
Even if you could convince everyone that installing an entire new VM to replace nginx is a good idea, I still don’t see how it would fit.
Both GitHub and Heroku use Cowboy in a place where people might more commonly use Nginx (file server, reverse proxy), so is can be used in this fashion.
I suspect we’d never be able to fill the shoes of Nginx as deployment of Cowboy/the BEAM is considerably more fiddly than deploying Nginx.
I cannot speak to using Cowboy as a full-featured replacement for nginx. I admit to be largely ignorant of the full scope of how nginx is “typically” employed.
However, I have had some good luck replacing functionality of tools like nginx and Apache in some of our systems through Cowboy in paths that lead to Phoenix applications.
For example, we found it was most convenient when writing the router and follow on code for a Phoenix application for that code to assume it was running at the root domain of a site. However, in production we wanted to run the application behind a Kubernetes Ingress controller that addressed the application other than the root domain. The problem is that the ingress controller would, or would not, strip off the non-root path for us as the folks administering it changed things over time. Frustrated what we did was write some Cowboy middleware that made our application agnostic as to whether or not the initial path component was included by the ingress controller.
Essentially we created a rewrite rule in Cowboy. It was implemented in code, which meant it wasn’t as convenient as changing a config file (as one might do for a rewrite rule in nginx or Apache) but it was possible.
Based on that kind of experience, I suspect you could add a configuration layer to Cowboy and perhaps develop a set of stackable Cowboy middleware to add proxying and rewrite capabilities through (for example) config files.
Yes in Where you need More than a single round-robin .
For example I have 6 Node and each
Handling Some Special user for
Example you think Node-A handle
User live in New York and those
Study in College X .
Because this node have To much Data about City and many other Things , and i not
Want all 6 machine Store All Data From each City and be replicate of other …
This Model need a Powerful routing system.
I believe Heroku Have like this idea and choice Beam instead of Ngnix
This case is to much great in Erlang
Because can use built-in Stable , real-time Db ( mnesia )
And Beam is To much Stable in Multi core
Under high-load ( Powered by GC per process )
.
