Monday, January 23, 2017

Client Side Application

It is safe to assume that there are millions if not billions of servers out there that are spending precious CPU cycles to do rendering of web pages. Only to be consumed by clients that are way more capable than parsing a pre-rendered HTML document, maybe even more capable than the backend instance that rendered it.
Well what’s the alternative you say?

Single Page Application, SPA

A SPA typically consists of a single HTML document that loads a JavaScript that will do the heavy lifting of presenting structured data. This is not a new concept, what is new are the many frameworks and evolved tools that make it more convenient and practical to implement.
Modern JavaScript deployments are usually packed together into a single file using Node.js for compilation. This happens before serving any clients, meaning no additional compilation or rendering will be required by the backend server. It also opens up possibilities for transpiling a modern ECMAScript syntax that still will be compatible with older browsers.
A great example is the default React environment. It allows the developer to write in Javascript based on ECMAScript 6, as well as an optional syntactic sugar called JSX. This is all compiled into one file by using Webpack.
The component based way of developing in React is attractive and makes it easy to separate different concerns. There’s also no difference in creating a self contained application or an application that consumes external APIs for serving the result. Thus it’s scalable in a way that makes it possible to start out without a dynamic backend and add to it further down the road if needed.


Static Site Generator

A different approach than letting Javascript route the content is a static site generator. This will generate an actual HTML file for each page, just like in the old days. A templating language is used to specify metadata and logic for how these files should be generated and populated.
An example in this area is Hugo. The documents will be generated before serving any client requests, much the same way as the Javascript bundle example above. But that’s where the similarities stop. In Hugo, you can write your content using Markdown with additional metadata using Front Matter as well as templating using Go html/template.
This approach makes it possible to completely skip Javascript for security or simplicity reasons, however there’s nothing stopping you from including some components from Javascript. For example a commenting system for your blog posts such as Disqus. Hugo already comes prepared for this and have many examples in their extras documentation.


Benefits

Moving the complexity up to the client makes it easy to have a very scalable and secure backend, while also keeping it cheap and simple.

Security

By pre-compiling content like this, there will be no runtime interpreter to inject arbitrary code into, no databases to SQL inject and no dynamic processing to overload with a DOS attack. In the case of running Javascript, you will still have to take care for XSS attacks. Other than that, it’s pretty much impossible to hack your application. In comparison, the keyword Wordpress gives 152 disclosed vulnerability entries at the time of writing, only accounting for backend type of vulnerabilities.

Scalability

Since your application is static as far as the web server goes, you can easily host it on any available hosting provider. For example Google Cloud Storage allows you to upload your files and associate them with your custom domain. Another example is github pages that are completely free for open source projects.

Flexibility

As mentioned previously, if you need dynamic functionality you can always mix and match from different 3rd party APIs that is called to by the client. If you still need to develop your own functionality that relies on content that cannot easily be included client side, you can do so by exposing your own API. This will then be consumed by your application the same way as you would include any 3rd party.
A maintenance free environment for developing your own API is Appengine. Appengine let’s you develop your backend in a sandboxed environment that makes it inherently secure while also ensuring scalability. In the unlikely event of a failure, you can still present the clients with relevant information that is part of the client side script or have a backup solution from other API endpoints.
Having a flexible architecture allows you to focus on a responsive and cacheable presentation while including business functionality as isolated building blocks, possibly from multiple different endpoints.

1 comment: