This is part 2 of the blog article on JAMStack with architecture considerations and assessments of different scenarios. Part 1 of the article on benefits and players can be found here.
In this section, we explain what the building blocks of the JAMStack consist of and how they interact. A typical workflow is used to illustrate the application's journey from development to end-user.
Static Site Generators
Instead of a programming language, a Static Site Generator can also use a templating engine. For example, there is Liquid, which is used by Jekyll. For creating static content, these are just as good as programming languages. Control flows or loops can also be mapped using the syntax of most templating languages. You can even assign variables and use functions.
An overview of all known static site generators can be found at staticgen.com.
Content Management System
To connect static content a content management system (CMS) is used. There, even non-developers can insert content into the page generated by the Static Site Generator using a graphical user interface. This is done by the Static Site Generator addressing the APIs of the CMS at compile time, if the CMS is API-based. However, there are also CMSs that instead of deploying their content via an API, create a Commit directly on Git. This has the advantage that both developers and non-developers can publish their content via Git and no other system needs to be consulted.
An overview of all known content management systems for the JAMStack can be found at headlesscms.org.
In addition, if hybrid applications are involved, the content that cannot be generated statically is either uploaded to a server, or a serverless architecture is deployed. This can be the case with Next.js, as mentioned above, since there are also pages that need to be rendered by the server per request and are therefore no longer the same for every user.
Possible use cases for JAM stack
In this section, we would like to look at the relevance of the JAMStack topic for different use cases. In doing so, we present three different software use cases and evaluate their feasibility using JAMStack.
A static portfolio is a very simple website where the content delivered is the same for all users. A portfolio is a kind of business card on the web, informing visitors about services offered and ways to contact them. From this, the following requirements emerge:
- The content must load quickly.
- Various pages (e.g. contact, products) must be able to be displayed within the website.
- The content must be able to be expanded or changed.
This web page is the simplest use case. A typical landing page that displays a bit of information and doesn't need to provide any user-specific content. In addition, the web page is likely to be changed infrequently.
Our evaluation for JAMStack: A landing page or portfolio is predestined for implementation with JAMStack. The content to be displayed can be generated via static site generators, which are then delivered via a CDN. APIs can be completely dispensed with due to the simple functionality and the lack of user context.
A blog already brings other requirements with it. For example, multiple authors usually need to be able to create, modify, and delete a blog post. The created posts must be displayed on the website in a timely manner. In addition, it should be possible for the visitors of the blog to write comments on the respective posts. This way, visitors can also express and represent their opinion on the respective topic. Depending on the popularity of the blog, many comments can be made on a blog article, which must also be displayed promptly to the visitors.
Our evaluation for JAMStack: JAMStack works heavily with CDNs. Here it would be possible, for example, to store Markdown files that can then be interpreted by the application. To solve the problem with the different authors of blog articles, a separate Markdown file should be created for each author. In this file all necessary information like name, age, hobbies, biography can be stored. These Markdown files can, for example, be placed in a separate folder named authors. Now, the application just needs to be taught the path to the Markdown files and the structure of it and the problem with different authors is solved. As soon as the Markdown files are changed and checked into the Git repository, for example, the build pipeline is triggered and the affected web pages are re-rendered.
Similarly to authors, you can also proceed with blog articles. Here, each article should be dumped into its own Markdown file. This Markdown file is filled with the necessary content. The Markdown file can also be converted to HTML with the help of libraries, this way articles can simply be written in a Markdown editor. Just as with authors, articles should also end up in their own folder e.g. articles so that they can be interpreted by the application again. As soon as a change is made on the git repository, a new build is triggered that pre-renders the corresponding HTML pages.
But how does it work with comments? Comments are written frequently. Visitors have raised a controversy that needs to be resolved in the comments in a short amount of time. Should we then trigger a build every time a new comment is posted?
These are valid questions
The third and final use case we'll look at is a traditional online store. The user should be able to log in to the online store, and it is also necessary that the user can place orders and also view his current orders. The user has a shopping cart in which he can place items and of course he has the possibility to pay for the desired items at the end of the purchase process.
Many things doable, a few limitations
The blog article has shown that much is possible with JAMStack, but far from everything, and that it is necessary to assess in advance whether or not a JAMStack app makes sense for the use case. Nevertheless, the development of JAMStack is enormously exciting and the steadily increasing interest shows that JAMStack will play an increasingly important role in the development of web applications in the coming years. In many ways, JAMStack is definitely the future. JAMStack offers a variety of tools that contribute to a particularly good Developer Experience (DX), because the developer can focus on the implementation and thus a much better productivity is achieved. Also, the current trend of migration of corporations to the cloud gives hope that concepts like JAMStack will prevail in the long run.