Sample Site

What's Brewing

undefined

CMS Integrations with JAMstack Sites

Goal: Explore the possibilities of static site architecture and how it integrates with content management systems.

What we will cover:
  1. The concepts behind JAMstack
  2. Why static site generation does not have the limitations that it seems to have, including a demonstration from this site
  3. Integrating this with content management systems generally
  4. AEM and non AEM applications

JAMstack

The "JAM" in JAMstack is short for:

While it seems rather mundane and obvious, and could use a better name, it does imply some major shifts in terms of how to develop for the web.

This enables maximum performance. You simply cannot get faster than delivering static html. No server side rendering time, no client side rendering time. However doesn't this have limitations? What about when you have a million product pages to render, user specific data, and you want to build a single page application? Far from limiting this type of functionality static site generation enables it.

Static Site Generation

...is not so static

The "static" in static site generation means that the HTML that the user see's already existed before they made the request. The server simply delivers the prebuilt HTML, and no client side rendering or JavaScript UI libraries are needed. However this does not imply that the website is "static".

Static site generation can be integrated with:

  1. Content Management Systems
  2. Dynamic UIs
  3. Single Page Applications
  4. Progressive Web Apps

The Sample Site

As an example of these features lets look at... well... this website.

Performance

Two metrics define performance on the web:

  1. How much data do you send?
  2. How long does it take to render?

Static site generation and single page applications go hand in glove giving you the best of both worlds. You deliver prebuilt HTML - and only what you need.

These sub second response times to the server are then reduced to a few hundered milleseconds by using a service worker to precache primary pages and then cache other pages after the user makes a response.

Cached responses are used first and then the updated response is retrieved from the server in the background.

Dynamic Features and API's

Static site generation does not limit dynamic UI's and features. API's and cloud functions can be easily integrated into a statically generated site.

As a simple example I have setup this site with a checkout feature that sends a request to the server for product views and then sends the users selections to a cloud function for checkout. While the cart page is created using a little bit of JavaScript, it's "rendering" of the cart page is limited to requesting the statically generated "product previews".

For this example I have directly used the DOM API however this could easily be replaced with any JavaScript framework.

Considerations

Fine Tuned Build Hooks

When data changes only rebuild the views that uses that data. Properly implemented this scales indefinetly. A million product pages could be statically generated. When data for a product changes you only rebuild the product views that use that data.

Build Cost vs Data Request Cost

My first consideration was fine tuned build hooks. I will caveat that by saying it is not always neccessary. A complex site will require a complex build hook that knows what views to update based upon what data changed. This is not always necessary. Often it is easier to scale the power of your database and build system than it is to maintain overly complex build hooks.

User Data

User data needs requested from authenticated API's. While the idea of prerendering even user views is interesting, I have not heard of it being done. I think the more prooven route is to connect client side rendering to an authenticated API.

Single Page Applications

Not all build tools are created equal. It is important to select a static site generator that provides access to full pages as well as the content of those pages with no additional layout or metadata. This way a single page application can navigate to a new view by requesting only the content of the new page without also having to request the layout and metadata, which was already loaded.

Contentful and Netlify

For this site I have used Netlify to distribute the static files across a CDN. These static files are then updated with webhooks when code or content changes. The cart and checkout features are powered by a Netlify Function. These tools could easily be replaced with a different hosting service, CMS, and API.

Proof of Concept Next Steps

  1. AEM Content Fragments
    1. Could a JAMstack site simply be one of the channels that AEM content is delivered to?
  2. Translation
    1. AEM content fragments would be a proven solution to this.
    2. What about translation with Contentful?
  3. Configurable site hierarchy with Contentful
    1. My Contentful setup has a developer defined site hierarchy at the moment. However entries can be linked and this could be used to create a site hierarchy. How would this work?
    2. How could you source content from AEM and have a dynamic site hierarchy?
  4. Asset management.
    1. How could the AEM DAM be integrated with a JAMstack site?
    2. How scalable is Contentful?

Questions?