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 shiny, opencpu, and 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 ggforce, ggraph, tidygraph, and 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.

routr

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.

Wrapping up

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 ?