Edge Side APIs

A new pattern to build fast and reliable web APIs.

Transcript

1. Edge Side APIs A new pattern to build fast and reliable web APIs A new pattern to build fast and reliable web APIs
2. Kévin Dunglas ➔ Co-founder of Les-Tilleuls.coop ➔ Creator of: • API Platform: API-first framework • Vulcain.rocks: client-driven hypermedia APIs • Mercure.rocks: async and real-time APIs ➔ Symfony Core Team @dunglas
3. API, cloud, PHP and JS experts ➔ Scop, 100% employee-owned ✊ ➔ Democratically managed 💬 ➔ 55 people 🦄 ➔ Lille, Paris, Nantes, Lyon 🌎 ➔ contact@les-tilleuls.coop 💌 Les-Tilleuls.coop
4. ➔ REpresentational State Transfer: a network of linked web resources ➔ The architectural style of the web itself ➔ Internet-scale distributed hypermedia systems ➔ Designed for scalability, performance, simplicity and security ➔ Constraints: client–server, statelessness, cacheability, layered system, code on demand, uniform interface ➔ Specs: URI, HTTP, RDF, JSON-LD, Hydra REST(ful) © Nordic APIs
5. What Has Changed Since the 2000s?
6. Standards
7. HTTP/2 & HTTP/3 ➔ Multiplexing: ability to download many resources in parallel ➔ Binary protocols ➔ Headers compression and deduplication ➔ Stream prioritization ➔ TLS 1.3: 0-RTT resumption ➔ QUIC: No head-of-line blocking (especially useful on slow mobile networks) @dunglas
8. HTTP/2 @ Forum PHP 2018 HTTP/3 @ AFUP Day 2021
9. HTTP Cache © MDN
10. 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
11. 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
12. Infrastructure
13. 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
14. ➔ Huge cache with distributed nodes ➔ Providers: Fastly, Akamai, Cloudflare… ➔ Build your own: • Distributed HTTP cache ◦ Souin (free software 󰏃) ◦ Varnish Enterprise • anycast DNS and GeoDNS ◦ GeoDNS (free software) ◦ PowerDNS (free software) CDN
15. ➔ Similar to CDNs ➔ But can also execute code ➔ Serverless functions: Vercel, AWS Lambda@Edge, 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
16. Lessons Learned From the Frontend
17. ➔ An architecture for frontend development ➔ JAM: JavaScript, APIs, Markup ➔ As much HTML as possible is pre-built ➔ The resulting static files are stored at the edge of the network, in a Content Delivery Network (CDN) ➔ Benefits: performance and scalability ➔ JAMstack is used by default for the frontend part of API Platform (Next.js) JAMstack © jamstack.org
18. Static Site Generation (SSG) aka JAMstack ➔ ahead of time (build time) ➔ statics files stored at edge (CDN) Incremental Static Regeneration (ISR) ➔ on demand (runtime) ➔ documents refreshed at expiration or invalidation ➔ static files generated and stored at edge ➔ code executed at edge (edge computing) ➔ faster builds and higher cache rate Generation strategies
19. ISR + SWR (stale while revalidate)
20. Introducing Edge Side APIs
21. ➔ 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
22. 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
23. ESA: Architectural Constraints
24. ➔ 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
25. ➔ 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
26. 2. Atomic Resources 🚫
27. 2. Atomic Resources ✅
28. 2. Atomic Resources ✅
29. ➔ 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
30. ➔ 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
31. 4. Preload
32. Vulcain @ AFUP Day 2021
33. ➔ 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
34. 5. Push
35. Mercure @ Forum PHP 2019
36. @dunglas Preload Pre-generate 2 3 Constraints 4 5 1 Atomic Resources Progressive Push
37. ESA: Tooling
38. Tooling PHP API Platform • iri_only • cache invalidation (PurgerInterface) FOSS Servers Caddy • Souin • Mercure • Vulcain JavaScript • Ketting • Vercel SWR • React Query Providers supporting PHP • Fly.io (Docker) • Vercel • Lambda@Edge
39. Thank you, thanks AFUP! ➔ Any questions?