7 step guide to JAMStack webdevelopment in 2018

Combined with the proliferation of single page websites, and serving content dynamically via API calls, static website development has made somewhat of a comeback. While initially this might feel as step backwards, significant advantages can be obtained if this new approach is used for the right job. Recent developments in web technology have increased the potential of the concept.

The essential part of this approach is not even very complex. The main idea is to use modern automation tools to, effectively build, a static version of an otherwise traditionally dynamic website. First I will discuss what tools and components are used in the creation of such a website. Then I will briefly discuss in what way they are used to provide the elements needed for a standard web application. In the third and final part of this post I will look at the challenges and the advantages of this approach. Finally I will briefly discuss what this means for contemporary web development.

So what does a simple setup look like? I will start by addressing the obvious and necessary components. From there I will address optional and more advanced components that can be added to the setup.

• Static file hosting (AWS S3, Google App Engine, GitHub Pages)
• Template Language (Twig, Handlebars)
• Content (Content as a Service, Template files, External API)
• Task Runner (Gulp, Grunt, NPM)
• CI/CD (GitLab / GitHub)
• Function as a Service combined with an API Gateway (AWS Lambda, Google Cloud Functions)
• Cloud Database instance (AWS Dynamo DB, Google Cloud Spanner etc)

Static file hosting

The first thing we need to discuss is already common knowledge. Recently it has become really easy to host static files for the web. By just uploading your files to one of these services you are able to easily expose them through http(s). Several companies offer this type of static file hosting, however the two most commonly known vendors are AWS and GitHub. The options span from cheap AWS to free at GitHub. (Yes that is free as in ‘free beer’).

Template language

A fairly obvious critique of creating static websites is the fact that they used to be a nightmare to maintain. Let’s say you have a simple website comprised of about ten pages. You might have to change ten files if you want to change some common detail in those pages. Enter the second component a template language. Traditionally a dynamic webserver, would be used to stitch together the templates with the layouts on request. However in this setup we are going to pre build every page on the site so the webserver can relax and directly respond with the finished page. Would it not be great if we could add the flexibility of a CMS to this setup? I will discuss this part next but we need two more components to do so: content and a task runner.

Content

First you need a source of content, this can take the form of a couple of template files, but it could also be based on a Content as a Service provider such as Contentful. This basically enables you to focus on creating a great frontend without worrying about having to create and maintain a backend. Contentful exposes content through an API and it allows us to fetch the content during the build stage of the website. We recommend using contentful as it is a simple way to manage content for people who are not familiar with markup languages.

Task runner

As I mentioned before we need something to stitch together the templates and content. The best approach is to use a task runner and a watcher. The watcher will monitor the templates and whenever they change run the task that will effectively build the static HTML pages. This can easily be achieved by creating a corresponding gulp, grunt or even native node task for it. This is basically everything you need to create a simple but manageable static website. This stack supports huge amounts of traffic while being exceptionally fast and cheap at the same time. The next steps are geared towards further automation or supporting increasingly more advanced features of websites. First lets look at further automation of building the resources and static HTML files.

Continuous Integration and Continuous Deployment (CI/CD)

The first component of the more advanced part of this guide is to make use of CI/CD in order to relocate the task of creating the static pages and the resources to the CI/CD environment of your repository host. More accurately it is interesting to make a separate task for building and deploying because some tasks, like combining and minifying CSS and JavaScript and to some extend HTML can further increase the performance of the site. However it should be noted that at least basic knowledge on using docker and configuring your CI/CD environment is welcome, as things can quickly get quite complicated.

Function as a Service architecture

Of course most modern website have to do more than just show some content. How would we go about processing data in this setup? Recently I have written a couple of posts on serverless architecture. In essence this is the solution to the problem that static website’s pose in this respect. FaaS architecture makes sure a static website can communicate with a more intelligent API. Moreover it ranks at the top of scalable solutions as it couples a HTTP web endpoint to a preprogrammed function. Basically removing the need to have a (virtual) server to handle backend code.

Cloud Database

The last thing a modern web application needs is database interaction. Where function as a service solves the problem of accessing dynamic content, the cloud database can provide this dynamic content (for example product searches). At first glance it might look difficult to connect a database to this setup. Once again, this is something the dynamic webserver would facilitate. However several providers have started to sell database as a service solutions. With some even providing the opportunity to just use one table for very simple and elegant solutions. Moreover these cloud databases can easily be accessed from AWS Lambda or Google Cloud functions. Therefor finally eradicating the need for any dedicated server in this setup. This allows basically any website or -application to run as a statically hosted page. Therefor this approach makes creating scalable webapplication cheap and lightning fast.

However, every approach has drawbacks. Let’s look at some of the negative sides of this specific setup. Afterwards I will discuss the advantages and finally I will conclude which type of application is best suited for development along these lines.

Drawbacks

The most obvious drawback of this approach is the fact that it can be complex to manage this environment. For starters even the simplest setup (static html pages based on templates) can be difficult to manage for people who lack experience with HTML and/or templating languages. Moreover setting up an environment like this requires some trial and error at a bare minimum. Finally every additional step will increase the complexity more than the previous. CI/CD, FaaS and Cloud Databases are currently advanced solutions that require the skill of a DevOps expert. If you are not familiar with elements that are needed for this setup it can take quite some time to get started. If you just want to bootstrap a simple application this setup might not be for you.
A second issue is the fact that this specific approach is not very well suited for complex web applications. The setup we discussed here is specifically directed at creating high performing, but relatively simple, websites. In upcoming posts we can explore possibilities of creating webapplications based on static pages. Recent examples of other approaches are GatsbyJS (based on react.js) and nuxt.js (based on vue.js). They might be better at dealing with JavaScript heavy and complex applications.
In upcoming posts we might look to into other ways of creating a static version of such an application. Angular has the Angular Universal package but this relies on isomorphic rendering which is technically server side rendering of a webpage so this does not fit the JAMStack approach.

Advantages

However by now the advantages should be sufficiently clear. First, as promised, this setup should be lightning fast. Second, every component in this setup scales extremely well. Third, it is easier to keep this setup safe as the attack surface is reduced to the API endpoints that you use. Moreover the attack surface is reduced even further because the need to provide a separate CMS stack can be eliminated. Finally it is comparatively cheap. Static storage is cheap, with FaaS you only pay when a call is made to your function and the same applies for cloud databases. This means when your application is not used, you will not pay. This eliminates overhead that usually occurs when you need to pay a periodical fee for a VPS.

Conclusion

The final question that remains is for what type of projects this stack we described is best suited. By now it should be clear that this approach is most suitable for comparatively simple applications that have to scale well in high traffic environments. However, I can see this technique proliferating to more complex webapplications sooner than later. That brings me to what this means for web development in 2018. In general I feel like these developments will lead to a further decline of traditional backend languages such as PHP and Ruby.

Follow our channel or give me a clap if you enjoyed reading this (lengthy) post :)