Skip to content

Instantly share code, notes, and snippets.

@oliverdunk
Created February 28, 2017 22:24
Show Gist options
  • Save oliverdunk/da84ba8077f58e1e99fc948003bb326d to your computer and use it in GitHub Desktop.
Save oliverdunk/da84ba8077f58e1e99fc948003bb326d to your computer and use it in GitHub Desktop.

An increasing number of sites today are moving to JAMStack, which is an extremely viable option for hosting your next website. Put simply, JAMStack refers to the idea that the base of your website can be static markup and additional functionality can be added through JavaScript which communicates to an external API.

When hosting a site built in this way, there are a number of features which could come in handy. Many services such as GitHub Pages, AWS and Heroku are available, but choosing the one best suited to you can be difficult.

SSL

Ensuring a secure connection between visitors to your site and the server is extremely important for both peace of mind and SEO. Access to HTTPS as standard is common, but the level of maintenance needed can vary.

Heroku provides SSL on the majority of their plans, using a specific command to manually add a certificate file. This means that you'll need to either purchase a certificate from a recognised authority, or generate one for free using a service such as Let's Encrypt. AWS offer a similar setup, but the certificate needs to be added to a connected load balancer or Route53 instance. This can feel a little tedious and heavy compared to other options.

Cloudflare is another option, but you can fall into a trap like I did if you don't fully understand how the service is implemented. Some of the options provided terminate at their proxy rather than your server, meaning that only part of the journey is encrypted. To get around this, you can enable 'Full SSL' or setup the Authenticated Origin Pulls feature. If you're willing to spend some time reading into this, Cloudflare is definitely a great option and the automatic SSL management can be extremely appealing.

Form Handling

Once your site is up and running, it's likely that you'll want to accept form submissions for one purpose or another. For example, you could be collecting suggestions for the most useless website ever. Without access to the server, this can be trickier than it sounds.

With most simple services, like GitHub Pages, running a API and database externally will be needed. This could be done using another host, or through a service like Formspree. Formspree is a service which opens an endpoint for you to send data to. Once recieved, they will forward this to you via email alleviating the need to run this type of infrastructure yourself.

Deploy Previews

Let's suppose you've finished implementing your contact form (or any other change to your site for that matter), but are worried that you'll be swamped in emails if you don't test the site first.

GitHub Pages has no clear solution - you could clone the repository and deploy to each based on the stage of your development cycle, but weren't branches invented for a reason?

More complex tools like AWS require you to create two sites as well. This means that you'll be paying for two sites, rather than just one with testing functionality.

//TODO: Add additional options which do support deploy previews

Redirects

A key part of single page applications is in the name - they are built in just a single page, which dynamically loads in the rest of our content. As a result, it's important to have the ability to perform redirects to a single index.html file regardless of the actual request path.

To do this with services like GitHub Pages, you'll need to find a workaround. While I wouldn't be suprised if they implemented an easier option soon, currently the most common solution is to hijack the 404 page and use your index.html instead. This sounds almost too good to be true, and it is. A 404 status code is returned and without a doubt, this will be harmful in terms of SEO.

AWS allows redirects to be configured in their web interface, although it's a shame that you have to either rely on an API integration or set things up again each time you duplicate the site.

Prerendering

Prerendering is the process of identifying bots like search enginges through the User-Agent header, and serving them a prerendered page with all elements loaded to ensure that they are indexed currently. It's needed because we can't rely on them running JavaScript before searching through the content of a particular site. The bigger search engines like Google are getting much better at dealing with this themselves, but warming up the page regardless is worthwhile.

GitHub pages has nothing to offer, but I'm extremely hopeful for the future. It's an area which they could dive into without disrupting existing sites, and would be extremely beneficial to their offering.

The versatility of Amazon's offerings mean you could setup something similar by offloading requests with a specific User-Agent header. You'd need to setup a new service to recieve these requests and render the page, though, so simplicity is at stake. I'd say that this option is better suited to you if off the shelf prerendering doesn't offer what you need.

Prerender claims to have served over 12 billion pages to bots, and aims to take away the need to setup a prerender service yourself. A number of open source platforms like Meteor provide easy integrations which may appeal to you.

Notifications, Web Hooks, and more

If your site is finally up and running, it'd be nice to know. Webhooks are provided by almost all of the services I've mentioned, usually needing either a particular URL to visit or a piece of code to run.

With AWS, for example, you can use their Lambda service which is free for small volumes. You could set this up yourself, or use a framework built specifically to address this need. Serverless provides a CLI interface and workflow for writing code to be executed in repsonse to a particular event. This can then be used in response to a deploy, for example, to notify your team through their messaging tool of choice.

A look at Netlify

Personally, I trust Netlify for all of my projects. They are able to offer all of the features I've written about above in one place, and learning how to use them is always easy:

  • SSL is a one click installation, done from within their app interface. You can even enable an HSTS header to force the use of HTTPS by ticking a single box.
  • Forms can be managed by using the netlify attribute in your form's HTML. The rest can then be managed from the web interface, including handling where responses should be sent and what actions should be taken.
  • Netlify has a great Deploy Preview feature, allowing you to take a look at your site before it's even live. This is perfect for testing new features.
  • Redirects are made easy with a redirects configuration file (available free), which can be used for single page apps as well as to route users based on their localisation (paid plans only). They even have their Playground so that you can test these on the fly.
  • Prerendering is one click too!
  • Notifications are all manageable in their interface, and a wide range are supported. Webhooks are available to keep track of important events, and you can also be notified automatically in Slack or Email if anything happens which you'd like to know about.

I hope that this article helps in showcasing some of the features worth considering before picking your next website host. Whatever choice you make, JAMStack has hopefully come across as a great option which can benefit both the developer and user experience drastically.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment