Deploying your static news app like a Samurai

Picking up where we left off last week, today’s addition to the series is going to explore deployment options that can be mixed into a static news app recipe.

Like any Web application, the final step of publishing a news app – whether it’s static or dynamic – involves getting files onto a publicly-accessible server so that users can interact with it. There are two fairly distinct deployment paths:

1. The K.I.S.S.S. or “Keep it Simple Storage Service” approach
2. The “Elastic Compute Cloud” or “Elastic Beanstalk” approach

KISSS-compatible static apps

KISSS-friendly static news apps only require their compiled assets – HTML, CSS, images, JavaScript, and data files (CSV, JSON, etc.) – to be fully functional. The advantage of building a KISSS-compatible static news app is the fast, inexpensive deployment to infinitely-scalable services like Amazon’s S3, Google Storage or Eucalyptus – basically, any storage service that is Web-accessible and includes index document and error document support.

It doesn’t get any less expensive than deploying an app to a service like Amazon’s S3, which is literally fractions of a penny per visitor, infinitely scaleable, and blazingly fast. Some well-known people, using static site generators like Jekyll, were pioneering users of S3 for website hosting purposes.

In contrast, some static news apps – as simple as they are – can still benefit from access to server-side processing functionality, like cron jobs that run the occasional dynamic script to collect or munge data. Amazon S3, however, does not support server-side scripting, so this is when the “server light” approach comes into focus.

A little bit more computing power

Because the objective of a static news app is to keep things as scalable, fast, and cheap as possible – when a little more computing power is needed – the next-best option is often cloud computing. Services like Amazon’s Elastic Compute Cloud, Digital Ocean, and Linode provide “scalable computing capacity” in the form of virtual servers that you configure to your specific needs. Provisioning is fast, and the cost is still very low for small applications. The trade-off is a steeper learning curve and the need to “manage” those servers.

Another option for many is the newer ecosystem of “Platform as a Service” (PaaS) providers, like [Amazon’s Elastic Beanstalk][beanstalk] or [Heruko][heroku]. However, the advantages that PaaS typically provides – automated app deployment, scaling, and management – is quickly offset by the more expensive pricing. Probably not a great fit for a static news apps most of the time.

All of the “server light” options above support adding a little extra power to a static app in the form of some Node.js, PHP, Python, Ruby, and even Perl.

How the pros handle deployment

So, taking all of the above into consideration, how do the pros like NPR and the Chicago Tribune do it?

The Tribune’s Tarbell app takes the approach of building the static assets (combining data and templates) and pushing them to pre-defined S3 buckets. That’s pretty much the only obvious deployment option with Tarbell.

NPR’s app template is also meant to be deployed as static assets to S3, but it also provides the option of deploying the app as dynamic Flask app. But wait, this is a series on static news apps!

The NPR approach is an interesting idea – a dynamic app that can “bake” out to a static app, similar to the LA Times’ work with Django bakery – but I’m curious about the trade-offs with this approach. For example, does the approach make sense to less technical contributors who are involved with the project? On the surface, it appears to provide a lot of flexibility at the expense of simplicity.

Pondering the deployment workflow

Okay, so how does this all work in practice, day-to-day, with a team? If you read through the documentation, the typical workflow for both the NPR app template and Tarbell appear to be:

• Copy a template, or install an app (Tarbell)
• Bootstrap or configure the project, which will create a git repository (and possibly add a remote repository on Github)
• Work on the project locally
• Build the assets & deploy the project remotely

I may just be overlooking something, but it appears to me that both of these workflows don’t force the developer to commit their current work before deployment, nor do they appear to force the developer to make a pull request to ensure they’ve got the latest code before deployment. No doubt these steps are almost like a reflex to the news app developers on those two teams, but may be overlooked by the less experienced.

I’m also left wondering how both avoid a situation where two developers deploy updates to S3 at the same time from different versions of the code that they have running locally? Again, it may just be second nature to the people working with these projects day-in and day-out to take the necessary precautions.

(NPR’s app template is smart about this for the EC2 deployment, I should note.)

Other routes to deployment

There is a middle ground between these two approaches, however, for those seeking a balance between the simplicity of deployment and speed of development. It’s also an approach that would seem on the surface to enforce good collaboration habits vis-a-vis source code management.

There are many variations and customizations, but the main patterns described in the Jekyll deployment documentation are good examples of middle ground approaches:

• Automated deployment with a Git post-update hook
• Automated deployment with a Git post-receive hook
• Automated deployment using a Jeykll-hook server

The concept that really stands out to me when looking at the DevelopmentSeed’s Jeykll-hook server approach is that it could enforce good workflow practices around deployment, even to services like S3 – it’s basically a proxy between the source code, the built code, and the deployment destination. Using a service like this means that the app is deployed using Git/Github, which means that all local changes to the app are committed before the deployment happens.

I’m curious to see that if that “source code to S3 proxy” concept will be extended to other static site generators, like the app template and Tarbell eventually, or to understand if they have another step in their workflow that handles those concerns.

Well folks, there you have it. There are LOTS of options for deploying your own delicious-tasting static news app recipe. Experiment, explore, and pick the option that best fits with your own way of doing things.

I’ll move on to “Working with data in static apps” in the next post.

If you have thoughts on the above – examples of other approaches, corrections, tricks, or just opinions – please add them in the comments or drop me a line on Twitter.

If you’d like to be notified of the next post, just subscribe to the comments and I’ll post the link there.