victorspringer / http-cache Goto Github PK

Hello, I'm working on a maintained cache system which one can be run out of the box and compatible with Caddy as caddy-module. It supports the RFC-7234 and the new one concern the Cache-Status. I would be proud to work with you on this because you did a great work on this project.
Then it supports Olric for distributed cache, Ristretto for high-performance and redis too. Then it's easy to implement a new provider by implementing a provider interface.
Check out the repo : https://github.com/darkweak/souin

Hi @victorspringer, first of all - thanks for a great project. http-cache is simple to use and has met all of my needs so far!

Recently I've been trying to gain more insight into the performance of one of my applications, and especially to figure out just how much impact the cache is having. I've been able to gather some simple metrics by shimming in an adapter, but there's significant context lost.

I'm wondering if you'd be open to expanding the API a bit to run some optional "observer" functions at certain times? I'm thinking specifically it would be useful to get a handle on the request or at least the request's context even in the case of a cache hit.

I'm willing to submit a PR for this work, but wanted to get your feedback first to see if this is something you're even interested in!

Hi,

Have you thought about using the HTTP PURGE method for handling cache purges? It'd be more standards complaint and allow this to be used behind/in-front of other products. Optionally some authentication for requests if someone is exposing their app straight to the network.

Thanks,

Karl

Badger would be an excellent storage adapter.
Pure golang.
Fast and designed for SSD drives.

I would also like to make this work as a grpc middleware. That would be really useful because it would work for both grpc and http thanks to the grocery gateway and other similar libraries.

The other thing is the caching logic in relation to the storage. You normally want intimate control of this and I noticed you had some really good generic algo . But often you want to be able to pin certain namespaces.
For example anything that was related to authourisation data you would want pinned into the cache because you always want it.
This together with warmup of an empty cache would mean your most important data is always there.

Just my 2 cents...

As far as coding styles the other issue before me commented a fair bit

Hi @victorspringer, this is my code review about this project.

Make sure it is compliant with RFC7234. Another good resource about http caching is the Mozilla docs.

You shouldn't commit the vendor folder as you acting as a library and not a application. Keep Gopkg.toml for ci and tests, so everytime you run a dep ensure the tests gonna be deterministic as they run against the same expected dependencies.

Don't really like the Config structure, initialize the values at the Client and then check if it has everything you need. But this is personal taste.

This function has some fixed rules, it may be ok, but you could accept as params a new function on parameters to change the behaviour. What if the user want to cache post? What if only 2XX should be cached?

This is my 2 cents.

In redis I can set TTL equal to 0 for no expiration time, but cache.ClientWithTTL does not permit that.

Cannot build for 386 architecture for any platform. Constant frequency := 9999999999999 is too big :)

$ GOARCH=386 go build -o lol github.com/victorspringer/http-cache/adapter/memory
# github.com/victorspringer/http-cache/adapter/memory
../../go/src/github.com/victorspringer/http-cache/adapter/memory/memory.go:108:15: constant 9999999999999 overflows int

The adapter dependencies may be CGO or non-cgo, and may be undesirable to pull into a project if unused.

Add go.mod files into adapter packages to exclude those dependencies from the main go.mod; For tests, a separate package (and separate go.mod for the test/ package) would avoid those dependencies being pulled into the main go.mod

Hey @victorspringer, if you can help with these two questions, I'd appreciate.

• This uses "normal" memory, and does not expect a memcached instance installed, right?

• Would this be a good configuration for a Gorilla Mux router?

// Initialize the router
router := mux.NewRouter().StrictSlash(true)

//Memory Cache code
memcached, err := memory.NewAdapter(
  memory.AdapterWithAlgorithm(memory.LRU),
  memory.AdapterWithCapacity(10000000),
)
if err != nil {
  fmt.Println(err)
  os.Exit(1)
}

cacheClient, err := cache.NewClient(
  cache.ClientWithAdapter(memcached),
  cache.ClientWithTTL(30*time.Second),
  cache.ClientWithRefreshKey("opn"),
)
if err != nil {
  fmt.Println(err)
  os.Exit(1)
}
router.Use(cacheClient.Middleware)

Thank you!