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).
(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
- 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
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!
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
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
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
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
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!
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
✔ 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