Welcome to our blog! In this article I'm going to give you a quick overview on the technologies that we chose to employ to power our main website and this blog.
Our idea was to build a website which should be easy and fast to edit, with a clean design, and we wanted to be extremely fast for end users; we also wanted our own website to be a showcase for the technology that we work with daily.
The website is build with our own fork of Pelican, a static website generator powered by Python. Website pages and articles are composited from Jinja2 templates, in which Markdown text is inserted. The website is actually built from four separate Pelican solutions sharing scripts and some configuration: one for the Italian and one for the English version of the blog, one for the Italian and one for the English version of the main website; these solutions are compiled separately.
For images we maily employ svg paths; we dynamically optimize raster images. All of our fonts are served directly from our servers and they are available in eot, svg, ttf, otf, woff and woff2 formats, to serve each client with his most preferred file type; we have differente favicons for most common mobile and desktop devices, including Metro tiles for Windows 8, 10 and Windows Phone.
Our website is fully hosted using Amazon Web Services; specifically, our files are hosted on Amazon S3 and all content is distributed via CloudFront, their Content Delivery Network (CDN); we implement caching of all static content both in the browser and the CDN.
The whole website is served via HTTPS, doing SSL termination at the CDN level; the website implements end-to-end IPv6 and servers requests via the HTTP2 protocol when it is supported by the clients.
We use four CloudFront distributions: one for www.soluzionifutura.it, one for the apex domain, one for blog.soluzionifutura.it and one for the statics domain. We decided to deliver assets using a separate domain mainly for two reasons: to have a easier time writing caching logic and to serve these files without cookies. Every time you send an HTTP request to a server for a specific resource, the client sends every cookie associated with that domain to the server; by delivering static content via a dedicated domain we don't have to send those cookies in all requests for assets.
The SSL certificate is obtained and refreshed via Amazon Web Services Certificate Manager; access to the S3 buckets on which the website pages and assets are stored is only allowed through the CDN.
To work on the website - both the application and content - we work directly on a Git repository; the repository is hosted on AWS CodeCommit. By default, as tools for compiling, task automation and deployment, Pelican suggests Make or Fabric; we decided to use Gulp for everything instead.
Specifically, we use Gulp to concat and minify CSS and JS, resize and optimize images, additionally, we use Gulp to handle caching and invalidation of static resources. For this reason we build an npm module which we called gulp-rev-recursive.
This module creates a hash from the file content using SHA-256 encryption and it appends a portion of this hash to the file name: if the resulting file name is different from the previous one it means the file has been changed; otherwise, it means there are no modifications.
If the file was changed, the module recursively substitutes all references to the file in every file of the solution; then, it saves the modified file and does the same with every file that references it, and so on until the whole website references are consistent.
This way, if a static file which is cached either at the browser or CDN level is changed, the file will be renamed and all of its references will be correctly modified in the whole website.
At this point Gulp is going to make a zip file of the whole compiled solution and it's going to save it in our own deployment packages repository, asking the user to specify an application environment for which the solution has been compiled (development, staging or production, for example), and those who have deployment permissions are going to be able to deploy the website in the correct runtime environment using our own command line interface.
We are happy with our new website and we have a lot of implementations in mind which we are going to develop along the way; we also have a lot of content to deliver, both regarding our offering as a company in terms of products and services and in terms of technical articles for those who work in the field. For now we'd like to show you an image with our website's PageSpeed and YSlow scores, measuring our website's performance.