Crate hitbox

Source
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.