The ongoing discussion for Biff [1] prompted me to re-share my post because I'd like more people to understand this "other way". Outside Clojureville, it is not obvious most of these Clojure "frameworks" are not monoliths.
The consummate Clojurist's default (and very normal-feeling way) to build a web application (or any application for that matter) is to roll their own web stack from production-grade libraries.
Of course, this state of affairs is a double-edged sword, just like is true for traditional web frameworks. In my post, I try to go into the whys and the wherefores, building upward from first principles.
I'd say the nice thing with the Clojure way of building your own stack is it becomes quite easy to swap parts out. On a previous project we swapped out our web server three different times with minimal changes (jetty -> aleph -> httpkit) as for the most part they all shared the same interface.
After a while you get good at seeing where you want things to be configurable and where you don't. It also gives you the confidence to roll your own micro stack/framework which means you are not dependent on third party aggregates to adopt new features.
adityaathalye•3h ago
Thank you for the kind appreciation. Made my day :)
Yes; next to the sheer stability of parts, their fungibility is a business-critical feature of the Clojure ecosystem. Of course said fungibility does not magically manifest. However the effort to get there is "not much", I'd say. The use of "system" libraries, with some well-reasoned module design brings it pretty close to magic.
As in the post, a fungible, production-grade part can be just a multimethod (e.g. the router in the post). Why? Because "production" comes in all sizes. A small SaaS with a few hundred customers may chug along happily with a bunch of functions.
adityaathalye•6h ago
The consummate Clojurist's default (and very normal-feeling way) to build a web application (or any application for that matter) is to roll their own web stack from production-grade libraries.
Of course, this state of affairs is a double-edged sword, just like is true for traditional web frameworks. In my post, I try to go into the whys and the wherefores, building upward from first principles.
[1] Biff – a batteries-included web framework for Clojure https://news.ycombinator.com/item?id=44037426
andersmurphy•5h ago
I'd say the nice thing with the Clojure way of building your own stack is it becomes quite easy to swap parts out. On a previous project we swapped out our web server three different times with minimal changes (jetty -> aleph -> httpkit) as for the most part they all shared the same interface.
After a while you get good at seeing where you want things to be configurable and where you don't. It also gives you the confidence to roll your own micro stack/framework which means you are not dependent on third party aggregates to adopt new features.
adityaathalye•3h ago
Yes; next to the sheer stability of parts, their fungibility is a business-critical feature of the Clojure ecosystem. Of course said fungibility does not magically manifest. However the effort to get there is "not much", I'd say. The use of "system" libraries, with some well-reasoned module design brings it pretty close to magic.
As in the post, a fungible, production-grade part can be just a multimethod (e.g. the router in the post). Why? Because "production" comes in all sizes. A small SaaS with a few hundred customers may chug along happily with a bunch of functions.