Last summer, just prior to starting as an intern working for Hadley, I published
fiery, a flexible webserver framework that I had worked on during the spring. The reason why I developed
fiery amids offerings such as
plumbr was that I was missing a back-to-basic server framework with low overhead and freedom to program your server logic in the way you wanted. For all of their accomplishments I felt that the other frameworks had different goals.
fiery has always been intended to be modular, with support for adding plugins in order to augment functionality, but since publishing
fiery I’ve unfortunately been distracted by other projects (mainly
particles). During all this my bad conciusness about the
fiery standstill has nagged my though, and for several different reasons I’ve decided that now is the time to restart development of this ecosystem. This post is as much a help and incentiviser for me as it is an overview of my plans for prospective users.
The first piece of the puzzle to work on is my
routr package which was intented to be released rather shortly after
fiery itself but fell down the priority list as my visualisation packages gained traction. While the main functionality of the package is there, it’s rough around the edges and is in general need of a full code review and update. Once
routr is completed the whole act of writing server logic in
fiery will be much more streamlined and easy.
A Deployment scheme for fiery apps
fiery is both intended for local running apps in the same vien as htmlwidgets etc., for powering webapp server logic, and for services deployed to production environment. For the two latter there has yet to come a streamlined deployment scheme and this is of course a prerequisit for usage. My current plans, which will be developed under the
firestorm mantle, is to set up infrastructure for easily deploying
fiery apps as docker images and leveraging as much as possible from the docker ecosystem in terms of setting up load balancing and service discovery. Optimally all of this should be doable from within R and without fiddling with dockerfiles and other configurations.
Making (some) security easy
The internet is a wild place and you shouldn’t expose a sevice without at least some security measures. While not all of these shld be implemented at the
fiery layer, those that do should be as easy and obvious as possble. The
firesafety plugin package will attempt to collect all the best practices for secury http(s) and websocket communication with the big wide world
Taking caree of your data
Whether you’re building a stateful app where session should be managed, or a REST api, data needs to go somewhere. The
firesale plugin package will be the home of a fiery-centric datastore implementation, with support for sessions and the likes.
Demos for the demo god
No web framework is complete without example apps, hopefully along with easy-to-read guides on how to build them. I hope to be able to provide this as well down the line, though focus is of course on providing good R documentation.
That was a lot of words and promise without anything to really show for it. I’m acutely aware of that. The above provides a very loose overview of what I intend to do, but I’m in no position to provide a timeframe - you can read the list as sort-of prioritised thus getting a sense of where my spare time will be spend first.
Here’s to hoping I don’t get derailed again 😄