Demo Sites Are Weird
Authentication, disk space, and other challenges
How do you decide if a piece of software is right for you?
Sometimes you just have to take a leap of faith and set up something to see if it will meet your needs and still play nice with the rest of your systems. But it would be a lot easier if you had a metaphorical equivalent of a non-committal let’s-meet-over-coffee before you decide to take the next step and install the software.
Since the launch of Autotune, we have been approached by people interested in adopting it for their own newsrooms. While a lot of people didn’t mind diving right into the set up, a few people asked us “Is there anywhere I can try this out?”.
So we decided to build a demo site that allows users to try building projects and get a feel for the framework.
Fueled by some amazing coffee selection at the most recent OpenNews code convening in Portland, we tried to solve some of the biggest challenges in creating a demo site.
Authentication and Security
Autotune is built to work with an OAuth provider for authentication. At Vox Media, we use our very own Chorus OAuth for authentication, but Autotune can easily be tweaked to work with GitHub or any other OAuth provider. Even with these guardrails in place, the system relies on a certain level of trust. It was built to serve a news organization with a carefully controlled access list. After all, at its root, Autotune is a system that downloads code from the internet and executes it on your server.
The biggest challenge in creating a free-for-all system is striking the right balance between restrictions and permissions.
Fortunately, we had built in three authorization roles into Autotune—User, Editor, and Super User. These roles determine what themes and projects the user may access.
On the demo site all users are “editors” by default. Once you sign in via GitHub, you can create and edit projects. Unfortunately you cannot add your own blueprints, as it would be irresponsible to let the internet run unverified code on our server. But we’re happy to add blueprints to the demo site for you, just let us know!
Once we decided on the authentication method, we had to figure out where to host the demo site. Our first attempt was at hosting it on a Heroku dyno. The setup was smooth and we had the site running in less than two hours. But when we tried to add a blueprint, we learnt that Heroku is not suited for a system like Autotune that builds projects on the fly. On a Heroku dyno, a running project no longer has access to the build toolbelt. This rendered Autotune’s way of cloning and building a blueprint repo powerless. We could possibly have hacked up a solution. But it would have been significantly different from the Autotune you would get if you set it up on your machine.The easiest option, in the end, was to host it on Vox Media’s hardware. So with a lot of help from Carmen Sarlo, operations engineer at Vox Media, we got the demo site up and running.
Scale, Disk Space & Other Caveats
Autotune uses server-sent events (SSEs)—WebSocket’s less-popular cousin—to keep the UI in sync with the project build and sync statuses. Like WebSockets, SSEs also use long-standing connections, so supporting a large number of simultaneous connections requires a large number of web server workers. Our demo site is a very minimal single-box setup built to support a handful of simultaneous users—which is appropriate for the scope of the project.
Other aspects of the demo site differ from an Autotune production setup as well. Autotune can be configured to deploy projects to a remote Amazon S3 location, but on a single-box setup, the projects are stored on the disk. With a system that is open to public, we have no way of predicting disk-space needs—but since the site is a demo and not a final project-publishing platform, we can just delete older projects to make room for newer ones.
Kavya is a developer with a journalism habit. She joined Vox Media’s Storytelling Studio as an OpenNews fellow in 2015 and stayed on after her fellowship. Her first newsroom job was with the investigative team at the Palm Beach Post. Before that she was a developer at Microsoft.