Build a Website with Netlify and Publii – InApps Technology 2022

For many of us, the fortunes of various frontend technologies look as febrile as the pop charts. Lots of energy and excitement erupt over new things that are really rather similar to old things. Meanwhile, there are plenty of underlying trends that are quietly evolutionary. This article talks about one of those and encourages you to try it out.

The internet has never had a “target design”; it is just a series of pipes. But over time we have accepted that websites are nice and that if everyone follows the rules of HTTP requests and serves HTML pages that is the best way to satisfy most casual user demands.

An ecology of web servers, providers and developers has evolved. Basically, a user types a URL into the browser, the request is then routed to a web server, the server checks the user’s credentials and creates the appropriate page and sends that back up the pipe. Waiting a little bit for a page is always acceptable if that page is going to be precisely what you need.

And yet quite a lot of sites don’t personalize information at all. If the website will always show the same information to anyone, why do we need to go to a web server to generate it?

This introduces the idea of the static website. Like all industry terms it can mean slightly different things depending on the context, but on the original web, everything was a static site. The innovation then was the “hyperlink”, or the ability to seamlessly jump to different pages on different servers.

Technically a site had three good reasons for communicating with its origin server:

• The credentials of a user had to be checked,
• the site displayed regularly changing information,
• or the page was collecting information from the user to be consumed by the server.

With tools like javascript and modern browsers, the page itself can quite easily communicate directly with a service via its API. So a more accurate definition of a static page is one where the structure of the pages and site is fixed, and any injected dynamic information does not alter this. How a site appears on a specific device display is also decided by the page itself, probably with javascript media queries.

Most of us are aware that some sites are suspiciously quicker than other sites at loading. The internet today is still a series of pipes, but there are a lot of way stations that collect, store (i.e. cache), and even accelerate certain content for easier local access. This is not surprising — if I want to see the latest popular and heavily propagated cat meme, it should surely be easier to find or recall than an academic paper on the paucity of paving stones in Patagonia.

Indeed the internet relies on Content Delivery Networks (CDNs) to help speed up most requests. The CDN supports the idea of “the edge” being a valid place to cache documents, so as not to have to track down the original source.

So we have all we need to understand the Jamstack (or increasingly just Jamstack). The Jamstack is all about creating prebuilt static pages to be served directly from a CDN.

If you were wondering, the acronym is Javascript (for scripting), API (if needed), Markup (as in HTML and CSS). If a site no longer has a webserver behind it, then there are less obvious points of entry for malicious attacks — in short, the Jamstack is seen as more secure.

OK, but if we don’t use a webserver to dynamically generate and serve pages, how do we build sites? This is where static site generators come in. While these can often be developer-focused tools that need knowledge of templates and frameworks, there are a few generators that are effectively desktop applications. Once you have defined your site, the generator will build it ready for deploying to a CDN.

So in summary, all you need to get on to the edge is:

• Registration with a CDN hosting service.
• A static site generator.
• A domain name you control.

For example, I use Netlify and the site generator Publii with my domain, oversight.productions, bought from Hover. I built and still update the site with Publii, push it into Netlify, which then publishes it to their CDN.

Publii is an easy-to-use application that lets you build a website much like a classic CMS. Define themes and layouts, then add in your content. You don’t have fine control, but it is a great way to quickly create sites. But whichever of the many generators you try out, make sure it can make the type of site you want with the skills you possess.

You will need to set up a trust relationship between your domain provider and your CDN service. This should be a documented process, if a bit technically fiddly.

I altered the Hover control panel to redirect DNS traffic to Netlify:

And I added my custom domain to Netlify so it is registered as an external provider. You can then add any changes to DNS records you might need.

With Netlify, you are given a locally generated name and domain (I’m afraid that is all “dreamy goodall” is) which helps testing; you then add your custom name alongside:

On the Publii app, you can explicitly set up to build for Netlify. Note the need for a Site ID and a token:

Back on the Netlify site, you can grab that Site ID:

And on another screen, you will be able to create a fresh access token.

Don’t worry too much between the specific bits and pieces — once you establish a trust relationship between the tools, you will be able to build a site, then deploy it to the edge.

While doing this required some technical acuity, there was no need to write any code, and for a personal project, the only cost was for the domain name. Playing in this area also gives you a real feeling for the meaning of “serverless”.

So have a go, and enjoy whatever flavor of JAM you like best.