Cowboy as nginx replacement?

cowboy

#1

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.


#2

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.


#3

If your stack is not full Erlang/Elixir, would suggest to use Traefik as a replacement of Nginx


#4

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.


#5

How interesting. Do you have any articles referencing this?

@Julio Welcome to the community! We hope you enjoy. Also, thanks for Traefik, look cool!


#6

I’m afraid not, but Heroku have made some of the code public.

There is also a book on running Erlang at scale from Fred Hebert back when he was at Heroku https://blog.heroku.com/erlang-in-anger


#7

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.