Which technology stack is Pingdom built with?

Pump up the JAM - better applications for smarter clients

JAMstack scheme

JAMstack: noun \ ’jam-stak’ \

Modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt markup.

As the old Heraclitus said in his day: "The only constant in the universe is change." As experts in the development of web applications, we know that this statement is still relatively cautious. Between our first coffee in the morning and the last e-mail after work, new tools are constantly appearing to make our lives easier. As artisans of the web, we live and breathe constant change. Today I'm going to tell you about the changes we're going through as web professionals: the rise of the JAMstack and the “static” sites. A change that affects not only us, but also our customers. But first I will start with a little flashback to the good old days of web development.

Dynamic content management - with a bitter aftertaste

Before joining codecentric, I was an active developer for apps, software and websites. At the time we were experimenting with different site builders to get results quickly. Like most developers in this area, we ended up with two CMS systems (WordPress and Drupal) that provided many of the features we needed. At the time, it was the quasi-standard: it accelerated development processes (FE / BE) and gave users the ability to manage their site themselves, but that was a long time ago and the market has evolved.

Like many developers before us, we noticed after a while that not everything was working as perfectly as we had imagined. We quickly had pain at many points. Many functions of the CMS systems were simply too complicated and resulted in unnecessary overhead. Unfortunately, things are no different nowadays. CMS have sprung up like mushrooms; in the most diverse, very interesting variants. The flat file systems such as Kirby and Statamic should be mentioned here.

But much more important than this fact is the amazing comeback of the "static" sites. You may have heard of the new development paradigm, aptly referred to as JAMstack (JavaScript, APIs and Markup). Thanks to modern browsers, “static” site generators, CDNs and APIs, there is a clear transition away from dynamic, server-side applications to modular, client-side stacks. This change can also be clearly felt in the development, since many things no longer happen in the abstract backend, but rather in the frontend.

For our newcomers to the JAMsatck universe, we can describe this relatively simply:

  • The entire website / app is in a CDN
  • Atomic deploys
  • Instant cache invalidation
  • Everything can be in the GIT (markdown ...)
  • automated build processes

Different workflows in JAMstack vs. classic CMS architecture

Classic workflow

  • Build process and hosting run in parallel
  • A user requests a page. The request is processed and a number of operations take place that require interactions between the database, backend, server, browser and possibly different levels of caching.
  • Core updates are pushed to the production server, often through the good old FTP server (greetings to the cowboys?). Databases need to be maintained and updated.
  • Content updates are carried out by traditional CMS such as Drupal or WordPress.

JAMstack workflow

  • The build process and hosting run separately from each other
  • A user requests a page. The page is already built and is transmitted directly to the browser via the CDN.
  • Core updates are pushed by GIT and the application is rebuilt using modern build tools, such as a static page generator.
  • Content updates are pushed through GIT or handled by a static CMS.

Many of the points listed above have a number of advantages:

  • The separation of server-based and database-based operations eliminates many sources of error and security exploits.
  • The delivery of the static content via a CDN brings an enormous increase in speed and ensures a better user experience.
  • Less overhead and complexity ensure a breath of fresh air in the teams

Joking aside, there are various good reasons for the JAMstack from a developer and customer perspective. If you want to dive deeper into the subject, here are a few useful sources on the "static" Site Generators ".

Get customers excited about the JAMstack ?!

There are various examples and articles on the subject of JAMstack for developers, such as Smashing Magazine, SitePoint, Heavybit, Netlify, The New Dynamic and StaticGen. But we must not only look at the developer perspective, because our users are always the focus of our work. If we fire up the whole Buzzword Bingo in a developer group, we will of course receive positive feedback, as they are aware of the advantages of avoiding complexity and the hurdles of dynamic caching. But we cannot convince our users with such phrases. While we are busy learning to walk and run with the new tools, it is precisely because of this that it is all the more important to take our customers with us on this learning path. Because that is also part of our job as consultants: to make sure that we all speak the same language and understand the same thing.

So we have to ask ourselves the following question. How do I explain the advantages of the JAMstack to the customer?

Convert technical advantages into business benefits

The short and concise answer is: We have to speak in the customer's language. We have to make the complex issues tangible and understandable. Technical features should be converted into economic advantages for the user so that they are also tangible for him.

Let's take database queries and the delivery of CDN-based content as a simple example. We can summarize this very pragmatically under the point performance. But what does that mean for the customer?

It's best to grab a tool à la Pingdom or Google Lighthouse and use two similar pages (the same page, if you like), one as a dynamic and the other as a static version. You should then make sure that the customer sees the results in black and white and understands them. Take him by the hand and explain the results to him. Then you can get into the topic of page load time and explain that this is one of the most important points for on-site engagement and SEO. A simple association should be made from this:

  • Static page = faster page = better user experience & better Google ranking = more traffic & more sales

We come next to the server-side components that embody our standpoint of reliability. To introduce a plastic example, one could take a six-story house of cards. It can collapse very quickly and its structure is very complex and difficult to handle. In contrast, our static site consists of only one stick and is very easy to build and maintain.

  • Static side = simpler side = more security & reliability = fewer unexpected costs, more peaceful sleep 🙂

And last but not least, we can use the reduction in operating and development costs as a tough argument. By eliminating the large web server monolith, the databases, the plugins and the constant maintenance, we save x-thousands of euros per year.

Refute legitimate objections

While we're talking about a move to the JAMstack, there will be tech-savvy customers and the associated developers who raise legitimate objections.

1.) The JAMstack setup sounds well and good, but I have to be able to manage elements dynamically.

At the beginning, the impression grows that JAMstack operated applications are static, but they are rather hyper-dynamic due to additional services that bring flexibility back into the setup. The assumed lack of server-side features is not a problem in today's growing API landscape and SaaS products. Rather, many functions are served on a silver platter. In other words, in the sense of cherrypicking, you can look for additional functions relevant to your project. Whatever dynamic functions and content you need, there is often a solution, which in turn leads to a nice, modular structure of the tech stack.

  • Webtask and the well-known serverless framework can take on a variety of backend functions.
  • E-commerce solutions in the form of Foxycart, Gumroad, Stripe or Shopify can provide this functionality with little implementation and maintenance effort.
  • Form processing or user-generated content can be elegantly implemented with Typeform, Google Forms, Formspree or the Netlify solution.
  • Search functionalities in various expansion stages (full text search, faceted search ...) can be easily implemented with services such as Algolia, Google Zustrom Search, Fuse.js, Luna.js and List.js.

But this is only a small excerpt from the services and tools that we can use. A good overview can be found on thenewdynamic or cloudcannon.

2.) Static CMS sound very interesting, but we have to manage different user rights and editor roles.

Here we find a real pain point that many customers address. But with the modern, headless systems such as strapi, Contentful, Prisma, Prismic or Directus, a clever role and rights system is already on board. However, if these systems do not address the customer's needs, there are other ways to solve this problem. You can use your traditional CMS as a backend UI, develop an API, and use your preferred tools to render the frontend. What is important here is the separation between the backend and the frontend. Many will now think of the decoupled system approach, which is completely correct inferred. Many of the well-known systems such as WordPress, Drupal or CraftCMS offer very extensive solutions here.

In the past I have dealt intensively with the topic. The provider Pantheon, the web application management console for developers, offers a lot of useful information on the subject of decoupled systems.

Now objections will come and statements that this stack is not exactly demanding. I agree as this approach overrides some of our arguments in favor of the JAMstack. But in practice, this is a good approach to introduce our customers to the topic more slowly than to bring about a complete technical break. The migration costs to a completely new stack should also be taken into account and are not so important in the previous example.

Suitability for everyday use and success stories

If we haven't jumped on the new bandwagon together yet, despite all the benefits from a technological and economic point of view, we should use an old trick from marketing. We are already showing successful projects that use this stack efficiently. Many large companies are already using this stack, such as Red Bull, Mailchimp, New York Times, Sequoia Capital, and Smashing Magazine. Further examples can also be found online, for example in the Site of the Week section of netlify, in the Contentful Customers area or in the showcases by gohugo, Jekyll or Gatsby.

There are of course many other possibilities from a sales, economic and technical point of view to move our customers towards JAMstack. But first of all, picking them up on the topic and making them aware of it is our first major task as a consultant. Because at the end of the day and the process, the needs of the customer are in the foreground and they want to conveniently edit, update, change images, create promotions or various other activities that are necessary in the digital age of the web.

"Static" Site CMS, JAMstack Toolchain and System Limits

In order to solve these customer problems, so-called “static” CMS have been established. There are various possible solutions in the form of self-hosted systems, SaaS and BaaS products. I will go into more detail on the subject of headless CMS in a following article with a practical example.

I would like to give a short list of tested systems as an example, and of course the system landscape in this area continues to grow.

As developers, we value the degree of professionalism that goes into these products and - much more important from the user's point of view - the simplicity of managing content without technical background knowledge. From experience, however, these systems also have some disadvantages; especially in the area of ​​SaaS products and the corresponding expandability and adaptation of the user interface. I list some of the criticisms I noticed below:

  • UIs are sometimes not intuitive enough and can only be adjusted sparingly.
  • UIs are not always optimized for mobile use and prevent efficient, mobile working (a workaround would be the development of a separate mobile editing app)
  • Media upload is often very rudimentary and does not always use the latest features such as intelligent cropping to deliver responsive and device-specific content.
  • Some systems force us to use the implemented CDN, hosting, SSL or deployment functions.
  • There are systems that only support firmly defined “static” site generators and thus limit our choice of tech stack.
  • The ability to define roles, access rights and user types is very limited in some systems.
  • Not all systems offer a useful preview function.
  • Multilingualism and geolocation are not included in various systems, but a trend can be seen in the last few months and is being followed up for the widespread SaaS products.
  • Dynamic features such as forms, logins, search functions or member management are missing in many systems, but can be implemented quickly using dedicated services.

It is a high level complaint, I am aware of that fact. But over time, these tools continue to grow and a clear trend can also be seen due to the growth and the associated customer feedback. However, the advantages of the JAMstack in the corresponding constellation outweigh the disadvantages and various products have already grown into fully developed products. A perfect example is the netlify platform. It covers all areas and enables a smooth implementation of the requirements required by many customers.

Are the JAMstack and "static" sites the best option for my customer?

The JAMstack is already established on the web application development timeline; For the developers it is already a finger exercise and the advantages in the areas of development, maintenance, performance and availability clearly predominate. After all, we don't want to be accused of technical debt.

In order to be able to finally answer the question, we are the topic driver in this case. The customer is pragmatic and relies on our expertise. In the end, it's the result that counts for him. So it is our job to analyze from the customer's point of view and incorporate the following factors into our evaluation:

  • Total cost overview of the solutions offered (consider budget)
  • Development, operating and maintenance costs
  • Knowledge transfer to the customer and learning curve in handling the new stack
  • Is the customer's knowledge sufficient to continue operating the stack or do we have to build the team together?
  • Have all the customer's technical requirements been taken into account?

To round off the article, I'll pack you some additional material and will prepare further articles on the topic for you: