Bandit was written specifically with the goal of serving Plug / WebSock and nothing more (it’s literally the very first line of the project README :). The reason for this is that at some point, you need to come up with some sort of abstraction to decouple your business logic from the underlying HTTP server logic, and Plug is about as simple of an abstraction as is possible to still be useful in practice. Cowboy’s underlying abstraction (‘handlers’) aren’t somehow any more magical than Plug; it’s still just a codified abstraction between an HTTP server and your business logic. Why José went with plug_cowboy instead of just building directly on top of Cowboy’s handler behaviour is a question for him, but my guess is that handler is actually a fairly awkward API to work with. plug_cowboy actually did (and does) a great job of smoothing that API out to something more usable in the form of Plug’s single call/2 based structure.

This isn’t to say that Plug is perfect, far from it. In particular, its pattern of ‘everything happens within a single function call’ means that it’s very awkward to do anything not directly related to servicing the request on the request process, at least not without involving other processes. Things like gRPC or implementing an event-aware MCP server are either not possible or else require some delegate coordination with another process. This isn’t entirely bad, or even an anti-pattern in the OTP world, but it does feel awkward in use at times.

Nor is WebSock perfect. Its spec came from extracting the existing (Cowboy-based) Websocket behaviour from Phoenix, and as a consequence is only able to send messages to the client as a return value from one of the handle_* callbacks; there’s no way to proactively send a message to the client.

My original design goal with Bandit was to very much intentionally lean on Plug as a simple abstraction, and to build the simplest thing that could turn HTTP requests into Plug calls. Every line of code in the project is laser focused on this goal; the fact that there is no lower level abstraction is kinda the whole point.

I guess my question back to you would be: if not Plug, then what?

This is the fact of life of using any non-trivial library. You use at most 20% of the code/functionality. I have to constantly remind me to keep away from 2 tendencies:

• Rewrite the 20% I use myself. My code will be most likely more buggy and less battle tested.
• Find some use for the 80% that I haven’t used. That will be like putting the cart in front of the horse.

I am not doing embedded programming, so unused code don’t bother me. In fact, I am against excessive package splitting. like: Phoenix, Phoenix_template, Phoenix_view, Phoenix_html? It only causes clutter and confusion.

But Plug is a great deal more than an HTTP server abstraction.

Ah, I see what you might be thinking. When I say ‘Bandit has Plug as a dependency’, I mean relatively few parts of the Plug Library:

• The Plug behaviour (ie: definitions of c:Plug.init/1 and c:Plug.call/2)
• A few general purpose definitions (Plug.Conn.Status as a ready-made list of status codes, Plug.SSLas an expert-built guide for configuring SSL cipher suites securely, and Plug.Conn.Utils for some header parsing functions)

Bandit doesn’t use any of the more ‘user-focused’ modules in Plug, such as Plug.CSRF, Plug.Router, Plug.Builder etc. Bandit’s mandate is to get from an HTTP request to a bare Plug call as quickly and minimally as possible (“Aim for minimal internal policy and HTTP-level configuration.” is Bandit’s second directive, subordinate only to HTTP correctness). We very much do not handle sessions, cookies (beyond crumbling as mandated in RFC9113) or any higher order functionality at all. The intent is that, if those are things you’re interested in, you build them into your app using the building blocks in the Plug library.

Really I was just surprised! I assumed Bandit was an implementation of an HTTP server and nothing more, and in my mind Plug sits “above that” as a level of abstraction with things like sessions and csrf and so on.

As explained above, your intuition here is correct!

Honestly I thought there was just going to be a callback like handle_request(headers, body) or whatever and I would take it from there. And I’m sure I could get back to that from Plug, but it’s just kinda sitting there awkwardly in the middle.

If you replace handle_request(headers, body) with Plug.call(conn, opts), you’re basically correct. The two primary differences are first, that the passed in header/body state is encoded inside a Plug.Conn structure, and second, that there are facilities for building a response in the Plug.Conn.put_* functions.