Nine Nines

Cowboy is great. It is a very perfomant, well designed and implemented piece of software. Also is mostly the work of one person -- Loïc Hoguin and his one-man 99s (Nine Nines) company. http://ninenines.eu/ So if you read this Loïc, thank you for all your work and for sharing it with the community.

Cowboy from Nine Nines has been going strong for years. With an anime mascot. An app you’re using right now could be using a project with an inappropriate anime mascot! I mean I get it’s not exactly the same, but I can’t think of a time anyone chose not to use Cowboy because of the mascot. https://ninenines.eu/

If anybody else is getting lost in the woods, hunting for change logs, this is the best I found: https://ninenines.eu/docs/en/cowboy/2.0/guide/migrating_from_1.0/

Kudos to the company for supporting Loïc Hoguin's work on Cowboy. One of my favorite features of Cowboy is its REST handling[1], which models a resource as a state machine with callbacks for various behaviors. The API is similar to Webmachine (another great Erlang project); I find it's a much clearer abstraction than mapping each HTTP verb + route to a function, which is what most "REST" frameworks do. [1] http://ninenines.eu/docs/en/cowboy/1.0/guide/rest_handlers/

You do sometimes have to be careful about how you handle configuration with embedding multiple copies of other supervision trees though: https://ninenines.eu/docs/en/ranch/2.0/guide/embedded/

Exceptions are ideal for happy path programming. You keep state in the stack and build your software so things get thrown away. For some types of programming this is not that important but for OLTP it is very handy. https://ninenines.eu/articles/dont-let-it-crash/ Basically this approach is handle errors if you know what to do with them, otherwise leave the error for something else. In erlang, where you have one process per transaction, and nothing handles the error, the process crashes. In C++, you could just have an exception handler around a transaction, and then when an exception reaches that point you throw away the transaction, but log that it failed, you could have exception handlers below this to try and do rollbacks etc. This is overly simplified but it gives a basic idea.

What is the advantage over Gun? (https://ninenines.eu/docs/en/gun/1.3/manual/)

Perhaps in part, yes. But cowboy does have a very powerful REST handler built into it that does a lot of the same things: https://ninenines.eu/docs/en/cowboy/2.1/guide/rest_flowcharts/

The announcement, including highlights: https://ninenines.eu/articles/cowboy-2.0.0/ Full changes: https://ninenines.eu/docs/en/cowboy/2.0/guide/migrating_from_1.0/ By the power of grayskull I invoke dang to update the link.

This isn't elixir fault per se. Elixir leverages Cowboy quite a bit and HTTP2 requires substantial rewrite of Cowboy. This will be completed in the release of Cowboy 2.0 If you want to read why Cowboy needs to be majorly refactored, read the link below https://ninenines.eu/talks/cowboy-2/#/

Just curious, was erlang.mk around and did you use the bootstrapped release / cowboy_http template [1] when creating your first application? Based on some things you mention, it makes it sound like you were writing from scratch while referencing the docs. :-) I also got started from the cowboy user guide (with prior Erlang experience), but found it relatively easier, as I used the template, then cross-referenced the idiomatic template with the docs as I worked through them (tweaking 'knobs' as I went along), which worked well in helping me understand the design. Along with the Erlang mailing list you've mentioned, I would also like to mention #ninenines (and #erlang for more general questions) on freenode. Very helpful communities! [1] This page describes the setup: http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/

Here's the cowboy user guide: http://ninenines.eu/docs/en/cowboy/1.0/guide/ You can also clone the repo and checkout the examples: Make sure you have erlang installed $ cd examples/hello_world $ make $ ./_rel/hello_world_example/bin/hello_world_example start OR $ ./_rel/hello_world_example/bin/hello_world_example console then visit localhost:8080

I only skimmed so far, but you might want to checkout Ranch instead of rolling your own tcp acceptor pool, http://ninenines.eu/docs/en/ranch/HEAD/guide/

Cowboy is roughly verb-agnostic (though REST verbs have special support: http://ninenines.eu/docs/en/cowboy/HEAD/guide/rest_handlers)

OTOH every decent erlang book or tutorial I've ready, from Armstrong's book[1] to Learn You Some Erlang[2] to Erlang and OTP in Action[3] and others all start off by introducing primitives like spawn, message sending , and receive. They then introduce OTP and explain all the cases it handles. I've never read a book or tutorial on OTP that just starts with OTP. In fact (a bit tangetially) whenever I encounter abstractions where I don't already understand the primitives I have a very difficult time. Maybe that's just the way my brain is wired though. I have a terrible time with OO programming for that reason. I much prefer a separation of functions and data because it's much easier for me to reason about what is happening. Anyway, I agree that programmers should start with the primitives, but I've never seen anyone really teach OTP any other way. Edit: also there are tools such as Erlang.mk[4] by Loïc Hoguin[5] that will handle a lot of the boilerplate for OTP projects and building releases, though it's good to do it manually at least once while learning. [1] https://pragprog.com/titles/jaerlang2/programming-erlang-2nd-edition/ [2] https://learnyousomeerlang.com/ [3] https://www.manning.com/books/erlang-and-otp-in-action [4] https://erlang.mk/guide/index.html [5] https://ninenines.eu/

Right, so this is basically the Go approach: explicit error checking on everything. No exceptions, because exceptions are a weird sort of non-local control flow, and can escape and take down your program as a whole. The "if you don't know the answer, find an approximation from another route" is .. situational. In this case it's exactly what the customer wants. In other cases (finance, security, aerospace) it could be a disaster waiting to happen. I worked on a point-of-sale system where it was a matter of design philosophy that any inconsistency should be an immediate crash-and-reboot; since it also operated as a save-everywhere and audit-everywhere system, if you did manage to crash it then within 30 seconds you'd be back at the screen just before the last button press with no data loss other than the button press that caused the crash. I believe this crash-and-recover approach is very Erlang: https://ninenines.eu/articles/dont-let-it-crash/ Thinking of exceptions and message validation also makes me think of "in band" versus "out of band" signalling and errors. Exceptions are "out of band" - outside the normal function return process. Internet communication is all "in band" and the whole approach of separate control and data planes has almost entirely gone away, apart from SIP and (nearly dead) FTP.

For those wondering what this is, I grabbed this from the zip file: = Cowboy Cowboy is a small, fast and modern HTTP server for Erlang/OTP. == Goals Cowboy aims to provide a complete HTTP stack in a small code base. It is optimized for low latency and low memory usage, in part because it uses binary strings. Cowboy provides routing capabilities, selectively dispatching requests to handlers written in Erlang. Because it uses Ranch for managing connections, Cowboy can easily be embedded in any other application. Cowboy is clean and well tested Erlang code. == Online documentation * https://ninenines.eu/docs/en/cowboy/2.0/guide[User guide] * https://ninenines.eu/docs/en/cowboy/2.0/manual[Function reference] == Offline documentation * While still online, run `make docs` * User guide available in `doc/` in PDF and HTML formats * Function reference man pages available in `doc/man3/` and `doc/man7/` * Run `make install-docs` to install man pages on your system * Full documentation in Asciidoc available in `doc/src/` * Examples available in `examples/` == Getting help * Official IRC Channel: #ninenines on irc.freenode.net * https://github.com/ninenines/cowboy/issues[Issues tracker] * https://ninenines.eu/services[Commercial Support]

My first attempt at making a simple Cowboy application was less than successful. I found the documentation spotty, inconsistent, and very difficult to understand. After about 45 minutes of really frustrated dicking around, I figured out how to make a simple HTTP server that allowed me to handle simple HTTP requests. I had to write code to switch on the passed-in HTTP verb, but everything worked, more or less. I could serve HTTP requests, but my code crashed after every request. (This was -of course- not fatal, but a bit of a performance killer.) Pipelined requests didn't work due to server connection resets. (Again, not fatal, just perf-diminishing.) I was utterly unable to get cowboy_rest to work. Several months later, with a lot of additional Erlang experience under my belt, I come back to the documentation, and it's -somehow- 60->70% comprehensible. I figured out what was wrong with my simple HTTP server. (I was calling my request handler in init, rather than returning {ok, Req, []}, and letting Cowboy call my request handler later.) I still can't get cowboy_rest to work, but (OTOH) I haven't spent more than five minutes trying to get it to work since my first attempt way back when. I don't know how much experience you have with Erlang, so I'll give you some basic advice that might be entirely unhelpful. Feel free to ask additional questions. Also feel free to ask questions on the erlang-questions mailing list. [0] Everyone who regularly posts there is very helpful.…

Another tool you might want to check out is erlang.mk, by the author of the Cowboy webserver, Loïc Hoguin -- from the announcement[1]: erlang.mk is a rebar replacement. It was initially created for allowing a faster development process than rebar and for better compatibility with Linux build tools. It should work on Linux and OSX with GNU Make installed. Here's how erlang.mk and relx can be used together to build releases (this is from a post by Loïc)[2]: There is two steps to building a release. First you need to build the various OTP applications you want to include in the release. Once done, you need to create the release itself, by including the Erlang runtime system alongside the applications, a boot script to start the node and all its applications, and some configuration files. erlang.mk solves the first step. It is an include file for GNU Make. Just including it in a Makefile is enough to allow building your project, fetching and building dependencies, building documentation, performing static analysis and more. relx solves the second step. It is a release creation tool, wrapped into a single executable file. It doesn't require a configuration file. And if you do need one, it will be a pretty small one. And here's a quick excerpt from a user-testimonial for erlang.mk, by Jesper L. Andersen[3]: When compiling from warm, it takes rebar 9 seconds to figure out that there is nothing to do in the project. erlang.mk does the same thing in 0.2 seconds. [1]…