Skip to content

Latest commit

 

History

History
29 lines (17 loc) · 2.72 KB

cache.md

File metadata and controls

29 lines (17 loc) · 2.72 KB
Raw

Cache Considerations

One of the advantages of the approach proposed by Vulcain is that it allows to leverage the full range of capabilities provided by the HTTP protocol, especially its caching mechanisms and its layered architecture.

Normalizing the API to Maximise Hits

To unleash the full power of Vulcain, API resources should be as granular as possible. Use links as most as possible. For instance, collections should only be collections of links, and should not embed the relations themselves. Doing this allows to have a specific cache for every resources. For instance, when fetching a collection, the client will not re-fetch elements of this collections already in cache.

Example:

  • The user arrive on a detail page, GET /book/1, stored in cache
  • The user click on the links to the collection, GET /books/, /books contains links to /books/1 and /books/2, only /books/2 is fetched because /books/1 is already in cache

Using Vulcain with Cache Servers such as Varnish

Vulcain plays very well with cache reverse proxies such as Varnish. A common setup is to put the Vulcain Gateway Server in at the edge of the network to be able to use Server Push, with a Varnish server behind it, and finally the application server behind Varnish.

The full documents (not filtered) should be stored by Varnish. To do so, Varnish should strip the Fields and Preload headers before forwarding the request to the backend server. This way, in most cases, the resources will be fetched directly from the Varnish cache (hit) and will be served almost instantly quickly to the Vulcain Gateway Server. The Vulcain server will then recursively fetch requested relations, and will filter the documents by removing useless fields.

Vulcain also plays very well with cache invalidation mechanisms such as xkey.

Preventing to Push Resources Already in Cache (Cache-Digests and CASPer)

When servers push resources that are already in the client cache, the client will cancel this push. However, it's even better to not send a push promise at all for resources already in cache. To do so, the new Cache-Digests for HTTP/2 RFC can be used. Alternatively, CASPer (cookie-based cache aware Server Push) can be used.

Note: the Gateway Server doesn't support Cache Digests nor CASPer yet.