1. ...a lazy developer’s guide
Tim Burt
Presented by
Dorset Digital
Silverstripe in the
Serverless Age
2. Today's Topics
1.What this isn’t
2. What’s the point then?
3. Right, what’s all this ‘Serverless’ nonsense?
4. ...so how can I use it?
5. Does it work?
6. What next?
7. Questions?
4. What this isn’t
•This is not a cure-all solution to your hosting
needs
•This is not an beautifully engineered solution!
•Not a replacement for your existing hosting
systems (yet) – especially on highly dynamic /
interactive sites
•Not a live demo ;-)
6. What’s the point?
•Make a quicker, more resilient and scalable hosting
environment
•Create a Proof of Concept
•Start thinking about site delivery in a different way
•Take advantage of existing technologies
•Do as little work as possible :-)
•Don’t spend a fortune on hosting!
•Make something that can be retro-fitted to an existing
site
17. Step 1: Move your assets
•With Silverstripe CMS 4, assets can be stored in
a remote location
•A single, common store for site content
• https://github.com/silverstripe/silverstripe-s3
18. Step 2: Improve distribution
•Add a CDN such as Cloudfront, StackPath, etc.
•Reduces latency, improves performance
• https://github.com/DorsetDigital/silverstripe-url-rewriter
Simple middleware to replace S3 URLs with CDN versions, eg:
https://s3.eu-west-2.amazonaws.com/stripecon.dorset-digital.net/public/image.jpg
BECOMES
https://d1bj1kucw3tvqr.cloudfront.net/public/image.jpg
19. Step 3: Site resources
•Serve site resources (CSS, JS, etc.) from a CDN
such as Cloudfront, StackPath, etc.
•Reduces latency, improves performance
• https://github.com/DorsetDigital/silverstripe-cdnrewrite
Simple middleware to replace site asset URLs with CDN versions, eg:
https://www.example.com/_resources/css/styles.css
BECOMES
https://cdn.example.com/_resources/css/styles.css
22. Step 5: Living on the edge
•Deal with web requests at the edge locations
•Most traffic never reaches the origin server
•Fast responses
23. Step 5: Workers
•Cloudflare Technology for running edge code
•Runs V8 engine
•Use Rust, Typescript
•Can respond to specific URL patterns
•Low cost
•Can contain conditional logic, can modify
requests and responses
24. Step 5: Workers KV
•Cloudflare Technology for storing data in their
network
•Simple Key→Value storage
•Keys up to 512 Bytes
•Values up to 2MB
•Can be given TTL for automatic expiry
25. Step 5: Our edge worker
addEventListener('fetch', event => {
event.respondWith(handleRequest(event.request))
});
async function handleRequest(request) {
request = new Request(request);
let requestedURL = new URL(request.url);
let urlPath = trimByChar(requestedURL.pathname, '/');
if (urlPath === '/') {
urlPath = 'index'
}
const kvdata = await kvstore.get(urlPath);
if (kvdata !== null) {
var requestTimestamp = new Date().toUTCString();
var myHeaders = new Headers({
'Content-Type': 'text/html; charset=utf-8',
'vary': 'X-Forwarded-Protocol,Accept-Encoding',
'server': 'Edge Hosting',
'date': requestTimestamp,
'x-worker-debug': 'KV Active'
});
return new Response(kvdata, {headers: myHeaders})
} else {
let originResponse = await fetch(request);
let response = new Response(originResponse.body, originResponse);
response.headers.set('x-worker-debug', 'Origin Active');
response.headers.set('x-path', urlPath);
return response
}
}
function trimByChar(string, character) {
const first = [...string].findIndex(char => char !== character);
const last = [...string].reverse().findIndex(char => char !== character);
return string.substring(first, string.length - last);
}
26. Step 5: Pushing the data
•We need to push the page data to our KV store
• https://github.com/DorsetDigital/silverstripe-edgepublisher
A publishing backend for the Silverstripe staticpublishqueue module
Utilises the existing processes for the selection, creation and storing of the
statically generated pages.
Can be used to interface with Cloudflare KV or AWS DynamoDB
Deals with the creation of KV namespaces via the Cloudflare API
Sends data directly to the edge data store when pages are published,
deleted, etc.
28. Yes.. so far!
•This is an alternative approach to distributed
hosting.
•Costs compared to a fully redundant,
geographically distributed hosting system on
Google Compute or AWS are extremely
favourable!
•Massively scalable, highly resilient
•More controllable than relying on HTTP proxies /
caching
33. Performance tests
• On a domestic broadband connection, response time of the first
request (TTFB) usually between 100-200ms (vs. 1-2 seconds on
the shared host)
• Repeat requests from same node TTFB generally under 50ms !
• Lightweight pages fully load very fast (even with browser caches
disabled)