@dunglas THE FUTURE OF API (PLATFORM)

@dunglas How it started

@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 Thanks to: a welcoming community

Meet, share and build together!

@dunglas API Platform Design Overview

@dunglas API-first: Building the interfaces that shape the world

@dunglas Y Easy to use while extensible and modular

@dunglas Good defaults, designed to prevent footguns

@dunglas The power of JSON-LD and schema.org For internet to become an open and global Knowledge Graph

@dunglas That automatically exposes structured and Linked Data

@dunglas To take back the web Save the web: Decentralize! @ AFUP Day 2020

@dunglas Because technology is not neutral, it’s political

@dunglas Hypermedia-driven APIs Enabling smart, generic, clients

@dunglas That you can customize to fit your needs

@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 Upgrading the architecture of API (Platform)

@dunglas Y JAMstack ✔ 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 ✔ As of API-P 2.6: JAMstack by default using Next.js © jamstack.org

@dunglas CDN and Edge Computing ✔ CDN: static files stored in servers all over the world ✔ Servers are as close as possible of end users - Low response times - Reduced bandwidth usage ✔ Edge computing: a CDN that can also execute code (lambas, serverless…) ✔ Some providers: Vercel (creators of Next.js), AWS Lambda@Edge, CloudFlare Workers... Distributed storage and computation © Cloudflare

@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 Static pages generation strategies ✔ Static Site Generation (SSG): - 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 © Next.js

@dunglas Introducing ESA: Edge Side APIs

@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 ESA architectural constraints

@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 Run API Platform @ edge

@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 API Platform 3: the foundation of your ESA API!

@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 Webperf: after Server Push @ AFUP Day 2021

@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 Webperf: after Server Push @ AFUP Day 2021

@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

@dunglas Thank you! Kévin Dunglas Follow me on social media @dunglas dunglas.fr / api-platform.com ASK ME ANYTHING!