Skip to content

Latest commit

 

History

History
60 lines (41 loc) · 4.05 KB

caching.md

File metadata and controls

60 lines (41 loc) · 4.05 KB

Caching

Caching is a mechanism that allow applications to improve how well they perform by minimizing the accesses to frequently-used resources. Caches can be in the backend, in the client application or even somewhere between them. Let's see how each API style takes advantage of this.

REST

One of the constraints of REST is, precisely, being cacheable. As it should be implemented as a layered system, an application cache (in memory, Memcached or Redis) can be used in the REST server.

Given its architecture, resource-oriented, with a single identifier for each resource and promoting the visibility, it is also straight forward to get the caching support native to HTTP.

In HTTP, caches are controlled using the Cache-Control header, which accepts these directives:

  • no-store - if a new request is done (because there is no valid pre-existing cached response), do not store the new response in the cache.
  • no-cache - responses can be stored. New requests will be validate against the server before being returned.
  • private - the response cannot be stored, unless by the client application.
  • public - the response can be stored anywhere.
  • max-age - sets the maximum amount of time in seconds, relative to the request time, to consider a resource fresh.

Example:

Cache-Control: public, max-age=604800

Note that a Expires header can be used to specify an absolute time to expire a cache. Although it will be ignored when Cache-Control is defined.

Cached resources are periodically removed or replaced (this process is known as cache eviction). Before its expiration time, a resource is considered fresh. After its expiration time, it's called stale. In addition, if a response included either an ETag or an Last-Modified headers, then the cache would be able to be revalidated.

Most apps will limit their cache only to GET requests.

It's important to note that highly customizable RESTful APIs won't benefit as much from the HTTP cache. If clients are able to request embedded resources or sparse fieldsets the odds to reuse a stored fresh result are reduced.

GraphQL

GraphQL servers expose a single entry point for the whole entity graph, so most of the time it cannot take advantage of the HTTP caching support.

  • Application cache can be used in the server side.
  • When tunnelling GraphQL through GET, HTTP cache can be used as well. We need to prevent mutations and subscriptions from being cached, though. For example, making it mandatory to run them over POST.
  • Global object identification can be used to unequivocally identify an entity in GraphQL. This tool let client developers easily maintain their local GraphQL cache.

gRPC

gRPC, like GraphQL, hijacks the HTTP protocol, so it cannot easily benefit from the native HTTP cache. However, default implementations of gRPC let API designers leverage ETag-based HTTP caching through the definition of a string-typed field named etag, that will contain the ETag identifier in it.

In addition, gRPC can also use:

  • Application cache in the server side.
  • Local cache in the client side as long as we implement a robust identifiers model, as the Global Object Identification proposal of GraphQL.

Resources