INTERFACE by apidays_Vulcain: beat GraphQL with HTTP/2+ by Kevin Dunglas

HTTP/2 Server Push 
and the rise of client-driven REST APIs

@dunglas - vulcain.rocks
Kévin Dunglas
❏ Founder of Les-Tilleuls.coop
❏ Creator of Vulcain.rocks, Mercure.rocks, API Platform…
❏ Symfony Core Team Member
@dunglas
.social

REST Performance

REST Performance
❏ REST is designed to solve
performance and scalability
problems at internet-scale
❏ REST relies on a powerful
caching model: clients and
intermediates can cache
❏ HTTP implements this model
© Google

The Under-Fetching and the N+1 Problems
Not fetching enough data initially forces to issue subsequent
requests, so creates waterfalls and increase latency.

The Over-Fetching Problem
Generating and fetching too much data (data not
used by clients) wastes bandwidth and computation
power.

GraphQL: an Alternative to REST « Fixing » its Perf Issues
(among other things…)

HTTP/2+

HTTP/2: Making the Web Faster
❏ Binary protocol, multiplexing, prioritization
❏ Server Push of resources
❏ Headers compression
❏ HTTP/3: good bye TCP (perf, again)

HTTP/2: Multiplexing
© Narayan Prusty

HTTP/2: Server Push

HTTP/2 global support: 
95% of all internet users

CloudWays Benchmark (Not Using Server Push)

Fast and idiomatic client-driven REST APIs
Introducing Vulcain

Pushing Relations

Consuming Pushes in JavaScript
const outboxResp = await fetch("/outbox", { headers: { Preload: "/orderedItems/*" } });
const outbox = await outboxResp.json();
for (const url of outbox.orderedItems]) {
    // Returns immediately, the resource has been pushed and is already in the push cache
    const activityResp = await fetch(url);
    const activity = await activityResp.json();
    // Do something with the JSON document
}

Benefits
❏ Fixes the under-fetching and N+1 problems
❏ Resources are downloaded in parallel (multiplexing)
❏ Granular HTTP cache (download only resources not
already in cache)
❏ Respects REST principles
❏ Leverages all features of the HTTP protocol
❏ cache, authorization, content negotiation,
extensibility…

Filtering Resources

Other Capabilities
❏ Selector negotiation: extended JSON Pointer,
XPath, CSS selectors, JMESPath…
❏ Support using Link preload headers and the103
Early Hints status code instead of Server Push to
preload cross-domain resources
❏ Use query parameters instead of HTTP headers
❏ Support non-hypermedia APIs through OpenAPI

The Vulcain
Gateway Server

The Vulcain Gateway Server
❏ Instantly turns any existing hypermedia or non-
hypermedia API into a Vulcain-enabled API
❏ Gateway server (plug’n’play network intermediate)
❏ Free software (open source)
❏ Fast, written in Go
❏ Easy to install (static binary, Docker image)
❏ Best performance: implement the protocol directly
at the app server layer

Starting the Gateway Server

Mapping a Non-
Hypermedia API

Mapping a Non-Hypermedia API
# openapi.yaml
openapi: 3.0.0
# ...
paths:
  '/books/{id}':
    get:
      # ...
      responses:
        default:
          links:
            author:
              operationId: getAuthor
              parameters:
                id: '$response.body#/author'
  '/authors/{id}':
    get:
      operationId: getAuthor
      responses:
        default:
      # ...
// /books/1984
{
    "title": "1984",
    "author": 1 // Not an URI
}
// /authors/1
{
    "givenName": "George",
    "familyName": "Orwell"
}

So… What About
GraphQL?

Vulcain vs GraphQL: Performance
❏ Unlike GraphQL, Vulcain sends each pushed resource in a
separate HTTP/2 stream (multiplexing): related resources are
sent in parallel
❏ Embedding resources is a forced push: the client receive the
full JSON documents, even if it already has some parts of it
❏ With Vulcain, clients can cancel the push of resources they
already have, saving bandwidth and improving performance

But GraphQL is More Than That!
❏ Query Language
❏ Type System
❏ Introspection
❏ Subscriptions
❏ Great tooling

Type System and Introspection
REST has that too… and a bit more!
❏ OpenAPI: type system and introspection
❏ JSON-LD: internet-scale type system, 
built on top of RDF, W3C standard
❏ Hydra: hypermedia introspection system, 
built on top of JSON-LD, W3C working group

Subscriptions

Tooling
❏ GraphQL provides great client-side tooling and an unified
Developer Experience, REST is still behind
❏ But because GraphQL uses HTTP as a black box:
❏ HTTP Cache servers (Varnish, Nginx…)
❏ standard WAF (ModSecurity…)
❏ HTTP logs analyzer (GoAccess, AWStats…)
❏ API Gateways (Kong, Gravitee…)
are almost useless

Tooling
REST also has modern, easy to use client-side and server-side tooling:
❏ API Platform (PHP & JS): create JSON-LD APIs and smart React &
Vue PWA, admin UIs, etc… in minutes!
❏ Graphiti (Ruby On Rails): create REST APIs in minutes
❏ Zeit’s SWR (React): Hook for HTTP APIs leveraging concurrent
rendering (Vulcain’s perfect companion)
❏ Our upcoming JS lib! Stay tuned 🤯
Vulcain works out of the box with all these tools!

Summary
Vulcain is:
❏ Fast (faster than GraphQL and JSON:API includes)
❏ Designed for the open web and interoperability at Internet-scale
❏ Easy to deploy
❏ Compatible with all existing tools leveraging HTTP
❏ Swagger/OpenAPI, log analyzers, Varnish, WAF, RDF…
❏ Can be supported in minutes by any web API
❏ including non-hypermedia APIs
❏ You can even use GraphQL to query a Vulcain API (apollo-rest-link)!
Give it a try!

Thank you!
vulcain.rocks - @dunglas - les-tilleuls.coop

INTERFACE by apidays_Vulcain: beat GraphQL with HTTP/2+ by Kevin Dunglas

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à INTERFACE by apidays_Vulcain: beat GraphQL with HTTP/2+ by Kevin Dunglas

Similaire à INTERFACE by apidays_Vulcain: beat GraphQL with HTTP/2+ by Kevin Dunglas (20)

Plus de apidays

Plus de apidays (20)

Dernier

Dernier (20)

INTERFACE by apidays_Vulcain: beat GraphQL with HTTP/2+ by Kevin Dunglas