Let’s define a framework as any library that contains one or more functions that accept callbacks.
Web frameworks are great for beginner developers who need to get stuff done. But they ultimately force you into a corner. In most applications, experienced developers need to retain control. Libraries are better. Developers can choose to use libraries, and any functions in them, judiciously.
By that definition, yada is a framework.
Since yada provides a handler, it takes control once the router has finished.
Since yada takes control away from the developer, it has to provide everything that a developer might need. This means that yada will never be sufficient, and will have to be endlessly maintained and features continually added.
I have since arrived at the opinion that what yada attempts is too ambitious. But the goal of providing libraries that make it easier to achieve greater conformance to HTTP specfications is still worth pursuing.
To that end, I’ve extracted out some functions from yada to make some supporting libraries.
For example, the regular expressions used in the parsing and construction of HTTP headers have now been given a proper formal treatment in reap. Likewise, the fledgling conneg.clj namespace (which yada copied from Liberator) has been subjected to a thorough, comprehensive, re-implementation with pick.
yada is async only. Almost by definition, a single thread per request is less complex.
The async nature of yada does make it more difficult to debug.
For me, yada’s most valuable insight yada is that it allows you to think about resources as Clojure maps. However, it would have been a better design if the maps didn’t contain functions (callbacks). The use of embedded functions ties what is otherwise a pure data representation to a particular language.
One of the architectural constraints in REST is the uniform interface. Consequently, it is better to have a single function, uniformly operating on a request (map) and a resource (map), as opposed to a custom individual function developed on a per resource basis. And yet, this is the design of virtually every other web framework today.
In HTTP, web resources combine configuration (which methods the resource allows, the acceptable content types of its representations, and so on) with state, the value associated with a resource at a given time.
Both configuration and state are time varying, indeed, as Roy Fielding writes in his seminal dissertation:
"a resource R is a temporally varying membership function" —
Given the dynamic nature of a resource, I feel that their configuration and state are best stored in a database, where they can be queried and consistently updated by client applications, rather than statically defined in a codebase.
Site is an experiment based on this idea, and I’m using XTDB because it fits my needs for a database where it is easy to persist time-varying Clojure maps. Though any other database could be used.
Unfortunately, Site isn’t (yet) a library or framework.
When I started yada, it was a research experiment to try to produce a Clojure web framework that would prioritise conformance to the HTTP specifications. As yada was adopted by a number of projects, and as these projects began to go to production, I felt it was inappropriate to make incompatible changes. Any new research into different approaches would have to be done elsewhere.
Also, at the time, there was some doubt about the future maintenance of aleph and manifold, which yada was built on. However, since then it looks like manifold is receiving some attention.
This year my research has been almost exclusively focussed on Access Control. Whereas authentication is mostly a solved problem these days, authorization is definitely not. I think Access Control is important for two reasons:
-
There are many appications which would be improved if they allowed the user greater control of their privacy, or the privacy of the individuals they store records about.
-
Access control is a significant fraction of the 'backend logic' that application developers are still required to write by hand.
Once I’m done with this phase of research I intend to invest further in HTTP conformance.
In the absence of a better solution, I would encourage senior developers building Clojure web backends to build their own handler, either based on the notes I’ve written up in rest.guide, or by stealing and adapting the code in Site’s juxt.site.alpha.handler namespace.
As I said in my 2021 talk "Building a RESTful Web API in Clojure - a new approach", you only need to build one more Ring handler. That handler can be taken from project to project and tweaked accordingly. This approach allows you to retain control, add features where necessary, focus on areas like the security required for your application and much more. It is more work up-front, but will get you to a much better place. The sacrifices involved in accepting the limitations of a web framework are just not worth it in the long-run.
Would love to hear you thoughts on the problem of access control! And whether you've considered a decoupled approach like OPA (which is the project I work on). As a hobbyist Clojurist, I've toyed around with integrations in the past, and more recently, me and a colleague have worked on a project for evaluating compiled policy plans directly in Clojure. Still far from being ready for production, but it's getting there :)