Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Introducing Edge Side APIs (#APIPlatformCon Keynote)

Kévin Dunglas
September 10, 2021

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).

Kévin Dunglas

September 10, 2021
Tweet

More Decks by Kévin Dunglas

Other Decks in Programming

Transcript

  1. @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 🤘
  2. @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
  3. @dunglas The power of JSON-LD and schema.org For internet to

    become an open and global Knowledge Graph
  4. @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
  5. @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
  6. @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
  7. @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!
  8. @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
  9. @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
  10. @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
  11. @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
  12. @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
  13. @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!
  14. @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
  15. @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
  16. @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
  17. @dunglas Thank you! Kévin Dunglas Follow me on social media

    @dunglas dunglas.fr / api-platform.com ASK ME ANYTHING!