Crate hitbox[][src]

Expand description

An a implementation and infrastructure for asynchronous and clear cache integration.

A quick tour of hitbox

Our crates consist of next main part:

Features

  • Automatic cache key generation.
  • Framework integrations:
  • Multiple cache backend implementations:
  • Stale cache mechanics.
  • Cache locks for dogpile effect preventions.
  • Distributed cache locks.
  • Detailed metrics out of the box.

Feature flags

  • derive - Support for Cacheable trait derive macros.
  • metrics - Support for metrics.

Restrictions

Default cache key implementation based on serde_qs crate and have some restrictions.

Example

First of all, you should derive Cacheable trait for your struct or enum:

use hitbox::prelude::*;
use serde::{Deserialize, Serialize};

#[derive(Cacheable, Serialize)] // With features=["derive"]
struct Ping {
    id: i32,
}

Or implement that trait manually:

impl Cacheable for Ping {
    fn cache_key(&self) -> Result<String, CacheError> {
        Ok(format!("{}::{}", self.cache_key_prefix(), self.id))
    }

    fn cache_key_prefix(&self) -> String { "Ping".to_owned() }
}

Re-exports

pub use cache::Cacheable;
pub use error::CacheError;
pub use response::CachePolicy;
pub use response::CacheableResponse;
pub use value::CacheState;
pub use value::CachedValue;

Modules

cache

Cacheable trait and implementation of cache logic.

dev

Structures and traits for custom backend development and testing process.

error

Error implementation and transformations.

prelude

The hitbox prelude.

response

Trait and datatypes that describes which data should be store in cache.

runtime

Cache backend runtime agnostic interaction.

settings

Cache settings declaration.

states

The set of states of the Hitbox finite state machine.

transition_groups

Module that implements transitions between states of the Hitbox finite state machine.

value

Cached data representation and wrappers.