Website 4.0

The story of the latest version of

I recently decided to refresh my website, as the previous version was very much geared toward selling my services, as I was a freelance web developer. That is no longer the case, so there is no need to advertise myself in such a way. I also wanted to giv myself a refresher on a technology that I hadn't used for a while.

The brief

I needed to redesign my site, so I started thinking about what I wanted to achieve with the site. Here are the points that I used as the brief:

  • The site needed to be informational, rather than sale-orientated
  • The site needed to be cleanly designed
  • The site needed to be quick
  • It should teach me something
  • It should be a good base upon which to add features quickly and easily

Let's discuss these points.

Informational, rather than sale-orientated

There is no need to try and get business from my site at this time, so I can remove all the sales buzz-words and concentrate on telling people who are interested a little bit about me. This means I do not need big call to action buttons everywhere, and can remove the contact button.

Clean design

The old design was OK, but it was a template that was not super easy to customize. It was heavy on imagery, which is unnecessary in the new theme because I want to make the site quick and hero the content. I wanted to go back to the drawing board and have a site that matched the logo that was previously designed for my business. Even though I am not looking for clients, it is a nice logo and it gives me a starting point in terms of colour palettes for the site.


That one is obvious, right? The hardware is of a good standard, so I knew I wanted to ensure the software was quick and would serve pages without much fuss. And I knew that I wanted less images this time around, so this would help factor into the speed too.

Teach me something

I love to learn, so I wanted this project to help me improve my understanding of some of the technologies I have used professionally but maybe not for a while.

Good base for future development

I wanted to ensure that I built the first version as simply as possible to get the job done well. This means that the time to release would be short, and that I can iterate on it after release. The platform should allow that, and also allow for new features to be added easily.

The choices

Based on these parameters, I made the following software choices:

  • Language: NodeJS
  • Framework: Express
  • Layout framework: Bootstrap 4

I have used Node professionally before, so this was a good chance to go back to it and continue my journey of learning. I have always enjoyed writing JavaScript, so this seemed like a way I could develop something rapidly, that would enable me to add features later very easily. It is a very quick language, as it is ideally suited to running real-time applications.


Express is a great framework for NodeJS. It is simple, powerful and allows for rapid development. I can easily add features too, due to the way the routing works I can add new sections without interfering too much with the rest of the site.


If you want clean, then you can't do much better than Bootstrap. Their layout framework is sensible, powerful and allows for a great deal of customization. I would write the styles using SCSS, which would give me a high level of integration into the Bootstrap environment, allowing me to use their styles via mixins or extends, and I could easily add my own code to create overrides or custom elements.

The development lifecycle

I wanted to get this site done quickly, but also correctly. I wanted to use modern tools like Webpack for the frontend, so I began by installing Express. After that, I started working on integrating Webpack and developed a script that would compile Bootstrap and allow me to add the CSS and JS to the site easily.

Once Webpack was working, it was a case of building out each page's route.

During development I ran two tasks, one to watch for changes to the SCSS files and one to serve the site. I am to improve this in the future if possible by utilizing hot reloading.


I needed a way to continue to serve some dev sites using apache from my site, but then serve the NodeJS application too.

I decided to use Nginx as a reverse proxy server, having it pass requests either to the apache sites, or the NodeJS app based on the incoming URL.

To do this, you simply create a server block for your new service in /etc/nginx/conf.d/default.conf and add the following code:

server {
  root         /path/to/codebase;
  # Load configuration files for the default server block.
  include /etc/nginx/default.d/*.conf;
  charset utf-8;
  location / {
      proxy_set_header      X-Real-IP $remote_addr;
      proxy_set_header      X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header      X-Forwarded-Proto https;
      proxy_set_header      X-Forwarded-Port 443;
      proxy_set_header Host $host;
  # Certbot config goes here!

Here, we are setting the server name, then loading in any extra config files.

After that, we set the character encoding to UTF-8, then we get down to business.

The location block determines how Nginx handles requests for certain resources within the parent server. You can think of it as the server controlling the domain, and the location handles everything that happens after that.

What we want to achieve is to pass requests from Nginx to the NodeJS server. This is managed by the proxy_pass directive. Before that though, we ensure the NodeJS server knows everything it needs to know about the incoming request. In order to reach this goal, we set the protocol, the real IP and the forwarded port. This is really useful for sticky sessions in load balancing.

The Nginx config sample above is available as a Githib Gist.

I think that about sums up the work I've done to launch my new site!

I may add more articles that deal with the setting up on Lets Encrypt and NodeJS process management, we'll see.