Nodeweb is a (not yet released) lightweight, flexible web framework on
top of the Hunchentoot web server. It aims for the niche between
Hunchentoot's easy-handler framework (which is very simple) and more
complex, thorough frameworks.
* simplicity implementation (so it can be easily understood, modified,
* simplicity of interface: does not require any complex concepts, one
can start with very little code
* extensibility: framework can be easily extended for needs of a
concrete application. Extensions can be shared, reused, composed together.
* modularity: if your application has several unrelated parts you can
keep them unrelated if you use nodeweb. But at the same time you can
reuse components if they are common.
* convenience: typical things should require absolutely minimal amount
of code. Less common things should not require complex workarounds.
* flexibility, compatibility: does not enforce any particular
application structure, can be used together with other Hunchentoot-using
code in one application. You can adapt your existing code for nodeweb or
you can use nodeweb from you existing code.
* minimalism, "no-bullshit": each feature should bring some value, not
a framework for a sake of framework.
So, what useful features it implements, compared to Hunchentoot's
To begin with, it has hierarchical dispatch and handling: if you have a
page with path /foo/bar, you probably want two nodes, foo and bar, with
bar being inside of foo. This would help you to avoid repeating
yourself, which has some known benefits.
Quite often parent node (foo in this case) would implement some
functionality common for all its children. For example, authorization.
Parent and child nodes can communicate: when request for /foo/bar is
being processed, handler for bar would be executed in dynamic scope of a
handler(s) for foo. This means that foo's handler can bind a dynamic
variable and bar's handler will see its value.
For example, you can implement authorization this way, in handler for foo:
(let ((*user* (get-user-from-cookie)))
Then all child handlers of foo can depend on *user* being bound to a
user object according to cookie in request.
Hierarchical dispatch is the main feature of nodeweb, its raison d'�tre,
if you wish.
But there is also a number of convenience features like integration of
HTML-TEMPLATE, JSON, error handling... And that's pretty much it.
So do not expect anything spectacular, it's just a framework to plug
your code into. (I do have some extra stuff, but it is specific to an
application and doesn't belong to core. Maybe it will be released later
in form of tutorial/recipes/add-on or something like that.)
Now about drawbacks:
* OO design might be objectionable
* heavy use of dynamic variables. I saw no way to use lexical scope
without making things overly complex.
* not enough documentation
* you have to use both nodeweb and hunchentoot API, hunchentoot API
* some things might seem over-engineered while other are under-engineered
* There is nothing hunchentoot-specific in nodeweb, so hopefully it
can be adapted for use with other web servers, and this would allow
making a wrapper API which hides web server details.
So, hopefully, same application can run both on Hunchentoot/SBCL and
Java servlet container/ABCL without modifications.
* I also see nodeweb as a platform for web-related modules. For
example, if you want to make a reusable JSON-RPC server library, it
makes sense to implement is as a nodeweb class: this way it will be
immediately usable in any nodeweb-using application, or any
Combining both directions it could allow to develop libraries which work
across different CL implementations and different web servers and are
directly usable, without adapter.
So, I'm going to release nodeweb when I'll write some documentation and
examples. But if there are people who want to take a look it right now,
before documentation is written (there is some documentation in code,
but it isn't extensive), I can share it privately. Send me an e-mail.