Introducing Edge Side APIs (#APIPlatformCon Keynote)
Here are the slides I presented during my keynote at the API Platform Conference. I introduced a new API architecture inspired by Jamstack: Edge Side APIs (ESA).
@dunglas Y How it’s going ✔ 8.9K commits in ✔ 17 Git repositories (PHP / TypeScript) ✔ 8.5M downloads on Packagist (just for core) ✔ 6.9K 🌟 on GitHub (just for the distribution) ✔ Awarded “best Symfony bundle” ✔ Ongoing: 1st API Platform Conference 🤘
@dunglas Thanks to: a diverse community ✔ 682 awesome contributors (code, docs…) ✔ 15 Core Team members ✔ 4,2K people on Slack ✔ Thousands of users, dozen of talks around the world ✔ 500 attendees (here and online) today 😍🎉 ✔ 15 amazing speakers ✔ YOU
@dunglas Summary: an API-first framework ✔ Full stack and fully-featured: - build APIs (servers) - consume APIs (clients) ✔ Easy to use: focus on your business logic, we provide the infrastructure ✔ Interoperable: implements web standards, exposes truly hypermedia APIs Introducing API Platform @ SymfonyLive Paris 2015
@dunglas I want to build my own edge infra! ✔ Caddy: the modern web server, perfect for your distributed applications ✔ Souin: distributed HTTP cache server available as a Caddy module, perfect for your edge ✔ Fly.io: run any Docker container, including API Platform and Caddy images, close to your users!
@dunglas Y ESA: Edge Side APIs ✔ An architecture for API development ✔ As much resources served by the API as possible are pre-built ✔ The resulting 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 and scalability
@dunglas Y ESA: Edge Side APIs ✔ ESA APIs can be written in any language: - PHP, JS, Rust, Go, LISP or anything else ✔ ESA embraces the REST principles ✔ ESA will be the core architecture of API Platform 3.0! ✔ The name is a wink to the good old ESIs… ✔ ...and to Thomas Pesquet
@dunglas 1. Pre-generate ✔ 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
@dunglas 2. Atomic Resources ✔ 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 cache hit rate - Clients fetch only what they need initially - Relations fetching can be delayed (on click…) - Less frequent re-generations / invalidations
@dunglas 3. Progressive ✔ 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 a 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!
@dunglas 4. Preload ✔ Preload relations initially 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
@dunglas 5. Push ✔ 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
@dunglas What a teasing! Upcoming: ✔ A book covering the ESA architecture in depth! ✔ A talk 100% dedicated to ESA @ Forum PHP 2021 ✔ An implementation: API Platform 3.1 ESA @ Forum PHP 2021