Right now I’m at Brussels Airport, waiting for my departing flight back to Zürich. The 10th European Lisp Symposium is over, and I got to have my first “real” talk at it. It was, as you might guess, about Radiance and some of the core concepts behind the project. With that, I think it is finally time to announce Radiance’s proper release into the wild!
It’s been a long time coming– starting back when I made my first steps in Lisp in June of 2013. Radiance’s full story started much earlier though, back when I was still dabbling in PHP and Java for most of my projects. The changes that this project has undergone since then are massive, to the point where hardly a single aspect of it now has any connection to its initial beginnings. One thing has always stood the same, though: the intention to make Radiance a framework that eases deployment and housing of multiple, different web services within the same instance.
So what is Radiance good for then? Why not just use Hunchentoot ? Well, depending on your project size and intentions, Hunchentoot may well be a viable alternative. What Radiance does do over Hunchentoot however, is that it offers you a layer around the webserver allowing you to exchange it later, similar to Clack . It also offers many more layers around various other features that are useful to develop web applications, however. Radiance is intended to be an adaptable intermediate layer between an application and the features that it depends on. It provides these features in such a way that it is still possible for the administrator of an installation of your application to decide what the implementations of those features are, and leaves them a choice to select their priorities.
Now, this probably sounds rather abstract and confusing, so let me try and illustrate what I mean a bit more clearly. Central to this aspect of Radiance is the standard-interfaces.lisp file and section 2 of the documentation. A quick look at them should make a few things clear: rather than implementing all sorts of features like a database layer, sessions, user accounts, authentication, and so forth, Radiance provides them through interface definitions. These definitions outline the signatures of functions, macros, and so forth that the interface provides. It does not, however, actually implement the features. Your application can make use of these features by depending on the interfaces it needs, without having to specify a particular underlying implementation. In the end, the administrator decides which implementing system to use for each interface, and Radiance takes care of loading the appropriate one whenever your application is loaded.
I won’t go into a discrete example here, as I’ve already described how to use interfaces and what they can do for you in increasing levels of detail in the conference paper , the documentation , and the tutorial . If you’re still with me and do intend on jumping in or having a more in-depth look, I really recommend starting with the tutorial. It’s lengthy and touches on pretty much every aspect involved in writing a fully-fledged web application from the ground up. It doesn’t touch on every single piece Radiance gives to you, but it will show you where to look and how to proceed should you still need more.
Outside of the interfaces and pluggable features, Radiance also offers a powerful and flexible routing system. Unlike other frameworks that associate pages with tags or directly hard-code the URL into the source code, Radiance uses an “internal URL representation” and an “external URL representation”. The former is what your application and templates speak in, and the latter is what the user and web server deal in. The translation between the two is handled by regular functions, called routes, which rewrite and transform URLs in order to achieve the URL namespace setup that is desired on a particular installation. This allows the administrator quick and easy control over the setup of an application.
Finally, Radiance has a built in configuration and file management system that is responsible for keeping all the run-time data of an installation in one place that is easy to track. It offers you easy access to application parameters that are configurable by the administrator, and bundles everything together in such a way that multiple configuration sets can be kept on the same machine easily, thus allowing you to switch between different setups quickly. For example, you might have a “development” and “production” setup on your machine that pick different settings and implementations for the interfaces.
Aside from these three major features of interfaces, routing, and configuration, Radiance offers a variety of tools and related functionality to help you with your development. In the end it is all constructed and written with the intention of making your specific web application work in such a way that it can be deployed on systems other than your own without much further work, and that it can be deployed alongside other web applications within the same Radiance instance. This allows the applications to share data like users, database, sessions, and so forth between each other, without tripping over each others’ toes.
While it is of course possible to use Radiance for an application that is just for you and you alone, this is not where its strengths lie. It’s intended for people that want to write web applications that can be redistributed and used by other people, and focuses on allowing someone to gather together the services they want and run them all together in a common environment, leaving them as much control over the system as possible without having to touch the applications’ code.
Now, mind you, this does have a price associated with it. You will need to give in to certain conventions that Radiance follows and give up certain amounts of control and freedom in order to really make use of the features. That’s how things go for everything. However, I dare say that the price is, in most cases, not very high. Most applications can be written with the tools the interfaces provide to you. And even if they do not, Radiance in no way forces you to use the interfaces. You can always break out of the layers and directly make use of whatever library you might need, at the cost of making your application share less with others in the system, or constraining the administrator further.
Because almost everything in Radiance is optional, it becomes rather hard to advertise it fully. I’m aware of the drawbacks and the strengths, so I can’t in good conscience just praise it for all of its aspects. The only thing I can say with certainty is that it’s a system I’ve worked with for many years now, and a system I’ve already written a bunch of applications with . I’ve also been running these applications on public servers for a good many years, so it isn’t without testing either. You’re actually reading this on one of my services right now.
In the end, it’s unfortunately still your choice which framework you’re going to use for your next project. I can’t make that choice for you. In the very least, though, I can now recommend Radiance without having to list a bunch of “but”s. Radiance is documented, it works, and it is now, finally, officially released!
I’d like to thank everyone who helped me along the way, by reading through my documentation and tutorial, testing things out, and giving me advice all around the project. I’d particularly like to thank Janne Pakarinen, Joram Schrijver, and Till Ehrengruber for their invaluable input.