What is JAMstack?

Short for "JavaScript, API, and Markup". In short, the idea is that a website/webapp doesn't need server side processing, but can be precompiled to a set of markup files and scripts that communicate with APIs to deliver dynamic and data-bound features.

In fact, this site - my blog - is built around the same philosophy. It is built on Statiq, which is a static site generator that works with .NET. (I had originally tried out 11ty, which was also fine, but built on Nodejs, and I really loathe the Nodejs ecosystem at this point)

What is this post about then?

I wanted to get more into this whole JAMstack way of thinking and see how easy it would be to integrate a data service through an API. So for a little experiment I will hook up Datatables JS library to communicate with a simple little dummy service. The service will have server-side processing and run separately from the blog, and then the blog should be able to keep living as a static side and still have meaningful functionality.

It is not that interesting really, because of course that'll work, but I still want to build out an example to show how it works, so keep reading if you want to stick around for the ride 😉

Time for examples

With a lot of local HTML and some JS, I can get this fancy table. It is still all local data though:

$(document).ready(function () {
    $('#example').DataTable();
});

However, with serverside processing, I can point the table to a service endpoint with a matching API and work with data from that.

This, in theory will let this bundle of precompiled documents serve as a dynamic frontend for data APIs that live independently.

Below is an example of a table generated based on an external API:

$(document).ready(function () {
    $('#example2').DataTable({
        processing: true,
        serverSide: false,
        ajax: 'https://simpledatatablesapi.azurewebsites.net/WeatherForecast',
        columns: [
            { data: 'date' },
            { data: 'temperatureC' },
            { data: 'temperatureF' },
            { data: 'summary' },
        ]
    });
});

Conclusion

It isn't very surprising that this works, but I think it is interesting that:

• It is so easy to do, while still keeping the UI application as "just documents"
• It promotes a healthy separation of services. What is UI and what is data? This of course without going overboard with microservices and message-busses and all that noise

I know I shouldn't feel too excited about this. It really is just going back to the basics. But it certainly is a breath of fresh air after being used to huge monolithic do-all-the-things services.