JAMstack

Eine neuartige Webanwendungs-Architektur

OUTPUT.DD 2019

@TheAlexLichter

Über mich*

Alexander Lichter

Nuxt.js Core Team Member

@TheAlexLichter

https://lichter.io

*erstmal über euch

Eine kurze Zeitreise

durch die Geschichte der Web-Entwicklung

Der Anfang

Server

1. Request

2. HTML

Dynamische Webseiten

Backend

1. Request

4. Dynamically generated HTML

2. Query

3. Results

Aber: "Click and wait" für jede Seite

AJAX und JavaScript

Server

1. Request

2. HTML

3. AJAX Request

4. XML (oder JSON)

Das SPA-Zeitalter

CDN

1. Request

2. Return Javascript

3. Parsing

API

4. Request

5. Response

Advantages

Kein komplettes Neuladen bei weiterer Navigation
Bessere UX verglichen mit "click and wait"

Problems

Langsame Time to first paint wegen Parsing
White screen / flash of content
Javascript generiert HTML -> schlechtes SEO
mittelmäßiges UX für initialen page load

Warum nicht "best of both worlds"?

Traditional SSR

SPA

Server Side Rendering

Node.js

Server

1. Request

4. HTML + JS

API

2. Request

3. JSON

5. Hydration nach JS Download

optional

5. Request

6. JSON

Und jetzt?

"Modernes" SSR

SPA

Traditionelles SSR

Statische Seiten

Single Page Apps

Server side Rendering

JAMstack

J

A

M

avascript

PIs

arkup

Statisch, wird nicht mehr vom Server geändert
Wird vor jedem (Re-)deploy neu generiert
Typischerweise mithilfe eines Static Site Generator (SSG)

Markup

<template>
  <p class="demo">
    <button class="btn-primary" @click.prevent="handleClick">
      <slot></slot>(clicked - {{count}})
    </button>
  </p>
</template>

Beispiel (Vue)

Verantwortlich für die dynamischen Komponenten
Nur client-seitig
Framework-/Libraryunabhängig

Javascript

Interaktionen mit der Seite werden über APIs gehandhabt
Werden via JavaScript über HTTPS aufgerufen
Oftmals Microservices, Serverless Functions oder ähnliches

APIs

Beispiel (serverless fn)

import { promisify } from 'util'
import sendmail from 'sendmail'

const shouldSend = process.env.SEND_MAIL

exports.handler = async (event) => {
  if (event.httpMethod !== 'POST') {
    return { statusCode: 405, body: JSON.stringify({ 'error': 'Method not allowed' }) }
  }
  try {
    const params = JSON.parse(event.body)
    const attributes = ['name', 'email', 'msg']
    const sanitizedAttributes = attributes.map(n => validateAndSanitize(n, params[n]))
    const someInvalid = sanitizedAttributes.some(r => !r)

    if (someInvalid) {
      return { statusCode: 422, body: JSON.stringify({ 'error': 'Ugh.. That looks unprocessable!' }) }
    }

    const sendMail = (name, email, msg) => pSendMail({
      from: email,
      to: process.env.MAIL_TO,
      subject: 'New contact form message',
      text: msg
    })

    try {
      await sendMail(...sanitizedAttributes)
      return { statusCode: 200, body: JSON.stringify({ 'message': 'OH YEAH' }) }
    } catch (e) { /* */ }
  } catch (_) { /* */}
}

TL;DR

Erstelle deine Website

via SSG

Uploade deinen Code

via Git

Lass den SSG deine Seite bauen

Deploy der statischen Files via CDN o.Ä.

Fertig!

QR Code Time

Aber warum JAMstack?

Performance

Simplicity

Security

Cost

Simplicity

Nur statische HTML-Dateien, kein .php / .py / ...
Man braucht keinen Server*
Keine komplizierten Deploy-Pipelines mehr

*hosting via. GitHub pages oder Netlify

Security

Keine dynamisch generierten Inhalte
Isolierte, kleine APIs
Idealerweise: "Content API" nur zur build time verfügbar

Performance

Bessere Time to first Byte durch CDN
Einfache Cache Invalidation
Schnellere Antwortzeit da statisches HTML
Optimal für SEO

Cost

Keine Servergebühren
Kostenloses Hosting (via Netlify oder GH Pages)
Serverless APIs werden nutzungbasiert abgerechnet

Wann sollte man nicht JAMstack nutzen?

Schnellebige dynamische Daten

Dann lieber SSR (z.B. mit Nuxt)

Live Demo? Live Demo!

Leseempfehlungen

Going JAMstack with Netlify and Nuxt - blog.lichter.io

Nuxt.js - An Introduction - Slides von meinem Nuxt Intro

JAMstack.org - Um mehr über JAMStack zu lernen