JAMstackin’ Cloud ready architecture for web sites

Story time: Guess the stack

10 pages of intranet information. Campus overview, organisational charts and most important telephone numbers. Updated 2-3x per year Liferay Portal

Foodie-Facebook! 1000s of members put recipes online, like and share. They can put recipes on their weekly food plan. Coaches can comment and help adjusting. Wordpress

An event page, where people can select seats and tickets to a multitude of events in real-time. They can reserve seats for friends who can buy within a couple of hours. A Java enterprise application

An event page, where people can select seats and tickets to a multitude of events in real-time. They can reserve seats for friends who can buy within a couple of hours. A Java Enterprise application, publishing 20 JSON files and 7 PHP scripts every other hour.

The tools of our trade

Hosting: Availability, stability, security Application: Process, state CMS: Data, structures, editors Front-End: Markup, CSS, JS

Technology Lock-In

Hosting: Availability, stability, security Application: Process, state CMS: Data, structures, editors Front-End: Markup, CSS, JS

Front-End

Templating languages

Static site generators

Data storage Fetch data Call renderer Renderer Deliver data Request Client Routing Render HTML Traditional “Pull” Architecture Deliver Response

Data storage Move all data, all possible content Renderer Render all HTML pages upfront in correct routes Request Client Routing “Push” Architecture of static sites Deliver Response

Hosting

  • Sources: Markdown, JSON, APIs It’s just HTML Deploy it: Storage, Dropbox Scaleable, blazingly fast, secure

Needs a build process Which increases as site grows bigger Not so good with binary data Some SSGs are more flexible than others

Hosting: Availability, stability, security Applikation: Prozesse, Zustände CMS: Daten, Strukturen, Editoren Front-End: Markup, CSS, JS

Content

That’s nothing for non tech-savvy users!

Going headless

  • CMS, not Content Design System 100% output independet For regular size projects free/cheap plans CMS status independent of site status

Git as a CMS -> Sounds good, doesn’t work Almost no good open source alternatives Big users pay big money What’s your content exit strategy

Hosting: Availability, stability, security Applikation: Prozesse, Zustände CMS: Data, structures, editors Front-End: Markup, CSS, JS

Applications

Serverless

Serverless is not about having no servers, it’s about not caring about servers “Functions as a Service”

It’s like developing for the browser, but on the server

const qs = require(‘querystring’) module.exports = async function(context, req) { const params = qs.parse(req.body) context.log(req, params) const message = { “personalizations”: [ { “to”: [ { “email”: “sbaumg@gmail.com” } ] } ], from: { email: params.mail }, subject: “Feedback from Website”, content: [{ type: ‘text/plain’, value: ${params.name} says: ${params.text} }] } return { httpResponse: { body: { msg: “Message sent!” }, status: 302 }, sendgrid: message } }

Accept: application/json Accept: text/html

Accept: text/html Accept: /

  • Pay what you need Manageable attack surface Defined Input and Output Integration with 3rd party services is easy

Serverless architectures are hard What about platform independence What if we like state More interfaces, more contracts

Hosting: Availability, stability, security Application: Process state CMS: Data, structures, editors Front-End: Markup, CSS, JS

JAMstack

J avascript A PIs M arkup

J avascript A PIs M arkup Templated markup prebuilt at deploy time. Using a static site generator. Deployable anyhwere

J avascript A PIs M arkup Server side processes and DB actions are abstracted into reusable APIs over HTTPS and JavaScript

J avascript A PIs M arkup Dynamic processes are done on the client. Via JavaScript. Deployed markup is extended with functionality from APIs client-side.

build deploy enhance

Focus on builds and deployment Prepared functions for common use cases Ready for most web sites All-in Serverless: Every language, every technology Builds through builders or commands Static tags along Enterprise level Cloud: Azure DevOps Azure Storage Azure CDN Azure Functions

No technology lock-in Incremental adoption

The most important thing about JAMstack is that you can start right away with a small piece of your current website.

Hosting Application Content Front-End

Hosting Application Content Front-End

Hosting Application Content Front-End

Sum it up

  • Every piece is independent Resilient, failsafe, sustainable Incremental adoption Full control of every part in your app

Lots of technologies: Fragmentation Very platform specific This is 3rd party land! Exit strategies!

Every web site and web app that can be done with JAMstack, should be done with JAMstack — Stefan Baumgartner

(every web site can be done with JAMstack) — Stefan Baumgartner

@ddprrt fettblog.eu · scriptconf.org · devone.at