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.

You are obviously going to have a far deeper understanding of this problem space than I do, so it’s entirely possible that my perspective here is not lining up with reality underneath.

But Plug is a great deal more than an HTTP server abstraction. As a completely random example, Plug includes an entire library for CSRF protection which is essentially no longer needed on the modern web. This is just the first thing that came to mind, but of course there is a ton of stuff in Plug that I just wouldn’t need or would want to reimplement myself. Cookies, sessions, and so on.

This is absolutely not the end of the world, and I could just treat Plug as a “dumb pipe”, using the simplest parts of its abstraction and ignoring the rest. But the question this raises for me is: why?

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.

Like on the client side, where Mint is HTTP, Finch adds pooling and a reasonable API, and Req adds high-level stuff. It would be very surprising if Mint had a dependency on Req, no?

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.

And fwiw my first thought after realizing this was “oh, thousand_island must be the real HTTP server”. But it’s TCP!

P.S. When I upgraded my Phoenix apps to Bandit I could not believe it was a one-line change. Thank you for however much work that must have been!

I suspected this was the case, though I wasn’t certain. Which is in part why I made this thread. Thanks for clarifying.

But can you also see that this is a bit weird? There are essentially two Plugs, a collection of low-level utils which you are taking advantage of, and a library of high-level stuff which you are certainly not going to need. This feels like an unfortunate mixing of concerns. Is there a universe where we could “split Plug in two”, here?

But if I want to build them without using the Plug library, which is the semi-hypothetical here, I cannot get rid of it!

And so if I want to build a framework with a non-Plug abstraction I have to take them back out, which is what feels wrong to me. Of course there might just as easily be a Bandit.Conn I have to take them out of, so it’s really just the fact that the rest of Plug is along for the ride that seems unfortunate I suppose.

I’d be curious to hear what others think. Thank you for the clarifications!