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

Edge Side APIs

Edge Side APIs

A new pattern to build fast and reliable web APIs.

Kévin Dunglas

October 22, 2021
Tweet

More Decks by Kévin Dunglas

Other Decks in Programming

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

    View Slide

  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

    View Slide

  3. API, cloud, PHP and JS experts
    ➔ Scop, 100% employee-owned ✊
    ➔ Democratically managed 💬
    ➔ 55 people 🦄
    ➔ Lille, Paris, Nantes, Lyon 🌎
    [email protected] 💌
    Les-Tilleuls.coop

    View Slide

  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

    View Slide

  5. What Has Changed
    Since the 2000s?

    View Slide

  6. Standards

    View Slide

  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

    View Slide

  8. HTTP/2 @ Forum PHP 2018
    HTTP/3 @ AFUP Day 2021

    View Slide

  9. HTTP Cache
    © MDN

    View Slide

  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

    View Slide

  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

    View Slide

  12. Infrastructure

    View Slide

  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

    View Slide

  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

    View Slide

  15. ➔ Similar to CDNs
    ➔ But can also execute code
    ➔ Serverless functions: Vercel, AWS
    [email protected], 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

    View Slide

  16. Lessons Learned
    From the Frontend

    View Slide

  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

    View Slide

  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

    View Slide

  19. ISR + SWR (stale while revalidate)

    View Slide

  20. Introducing
    Edge Side APIs

    View Slide

  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

    View Slide

  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

    View Slide

  23. ESA:
    Architectural
    Constraints

    View Slide

  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

    View Slide

  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

    View Slide

  26. 2. Atomic Resources 🚫

    View Slide

  27. 2. Atomic Resources ✅

    View Slide

  28. 2. Atomic Resources ✅

    View Slide

  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

    View Slide

  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

    View Slide

  31. 4. Preload

    View Slide

  32. Vulcain @ AFUP Day 2021

    View Slide

  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

    View Slide

  34. 5. Push

    View Slide

  35. Mercure @ Forum PHP 2019

    View Slide

  36. @dunglas
    Preload
    Pre-generate
    2
    3
    Constraints
    4
    5
    1
    Atomic Resources
    Progressive
    Push

    View Slide

  37. ESA:
    Tooling

    View Slide

  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
    [email protected]

    View Slide

  39. Thank you,
    thanks AFUP!
    ➔ Any questions?

    View Slide