Expiration ➔ max-age: duration the resource is considered fresh ➔ s-maxage: same, for shared caches Validation ➔ ETag: ID of a version of a resource ➔ Last-Modified: last modification date Invalidation (not standardized) ➔ Purge stale versions ● xkey / ykey (Varnish) ● Surrogate-Key (Fastly) ● Cache-Tags (Cloudflare / API Platform) HTTP cache
HTTP Cache: new New Cache-Control directives (extensions): ➔ immutable: the resource will never change ➔ stale-while-revalidate: use a stale response while asynchronously checking for a fresh one ➔ stale-if-error: use a stale response if the server returns an error @dunglas
Content Delivery Network ➔ Servers all over the world ➔ Stores static files ● images, videos, JS, HTML... ➔ As close as possible of end users ● Low response times ● Reduced bandwidth usage CDN
➔ Similar to CDNs ➔ But can also execute code ➔ Serverless functions: Vercel, AWS [email protected], Cloudflare Workers ➔ Docker containers: Fly.io ➡ Edge Code (distributed, ex: auth) ➥ Edge Cache (distributed) ➥ Origin (centralized, ex: main business logic) ➔ Or totally distributed: run PHP at edge! Edge Computing
➔ An architecture for API development ➔ Resources served by the API can be pre-built ➔ Generated static JSON documents are stored at the edge of the network, in a Content Delivery Network (CDN) ➔ Responses can be generated at edge (edge computing) ➔ Benefits: ● performance ● scalability ● reliability ESA: Edge Side APIs
ESA: Back to The Basics ➔ ESA can be written in any language: ● PHP 😍, JS, Rust, Go, LISP or anything else ➔ ESA embraces the REST principles ➔ The name is a wink to the good old ESIs… ➔ ...and to Thomas Pesquet ➔ ESA will be the core architecture of API Platform 3.0! @dunglas
➔ Pre-generate as much API responses as possible ➔ Store the API responses in a CDN ➔ On write, re-generate (or invalidate) all the API responses impacted by the change ➔ Optional: run code at edge Benefits ➔ Performance ➔ Scalability and reliability ➔ Less energy consumption 1. Pre-generate
➔ Serve small, atomic documents ➔ Don’t embed related resources, link them (hypermedia) ➔ Split big resources using one-to-one relations Benefits ➔ Developer Experience: simpler (no serialization groups…) ➔ Better browser and share cache hit rate ➔ Clients fetch only what they need initially ➔ Relations fetching can be delayed (on click…) ➔ Less frequent re-generations / invalidations 2. Atomic Resources
➔ The API must be usable by any client on any device (think curl + jq or raw TCP sockets) ➔ Capable clients can leverage optional features such as cache, preloading, HTTP/3 or push, for better performance and UX Benefits ➔ Works everywhere, even on old devices, in scripts… ➔ Top notch UX and perf with modern browsers/devices Reminder: to reduce the digital environmental footprint, we must build fewer devices and use them longer! 3. Progressive
➔ Preload initially relations needed ➔ Use Preload links (optionally with 103 Early Hints)... ➔ ...or HTTP/2 Server Push ➔ Allow clients informing the API of what relations they need: Vulcain, Prefer-Push Benefits ➔ Mitigate the n+1 problem ➔ Reduced latencies 4. Preload
➔ Clients can subscribe to real-time updates ➔ On write, new versions of the resources are pushed (do it when re-generating) ➔ Use Mercure, SSE, Websockets and/or WebSub Benefits ➔ Clients are always up to date ➔ UX: user interfaces update in real-time ➔ Less energy consumption: no polling 5. Push
dunglas
dalinaum
hollycummins
tmokmss
ayaka1230
ryu_hu03
shoheihosaka
k0kubun
fornewid
hideg
shimataro
shioyama
jasonvnalue
bkeepers
morganepeng
tanoku
revolveconf
shlominoach
jeffersonlam
akmur
holman
addyosmani
keathley