search

quarkusio / quarkus

Quarkus: Supersonic Subatomic Java.
https://quarkus.io
Apache License 2.0
13.82k stars 2.69k forks source link

Add http client caching support #22797

Open maxandersen opened 2 years ago

maxandersen commented 2 years ago

having a http client that could let you have client-side cache to avoid unnecessary requests and instead fetch from cache.

resteasy classic seem to have something https://docs.jboss.org/resteasy/docs/1.2.GA/userguide/html/Cache_NoCache_CacheControl.html#client_cache

Extra useful if the same physical) cache could be shared via java HTTP client useCaches(true), resteasy (reactive/nonreactive) and vert.x http client.

michalszynkiewicz commented 2 years ago

Quick googling suggests that vertx http client doesn't support it but it needs to be verified.

I think it's reasonable to target rest client reactive in the first iteration, both declarative and ClientBuilder approach

argenstijn commented 2 years ago

https://github.com/vert-x3/vertx-web/issues/881

michalszynkiewicz commented 2 years ago

related issue: https://github.com/quarkusio/quarkus/issues/16118

michalszynkiewicz commented 2 years ago

the linked issue, by @u6f6o says:

It would be nice if we could configure the quarkus rest clients to respect http cache headers returned by a remote server. In case these headers are present, the rest client could decide on its own, wether it should send a request to the server again or if a local copy of a previous response from a local cache could be sufficient. The etag header could furthermore reduce the amount of bytes transferred over the wire in case the etag matches the latest server version.

These mechanics are quite common in our case, especially in our client applications (android, ios etc.). Frameworks like okhttp support these out-of-the-box and it works best for resources that do not change very often (static files etc.). It would be nice if we could use the same techniques on the server-side as well. Aside from the reduced traffic, we could have more control on the server-side as we could easily change the expiry dates for certain resources.

I am aware that there is a suggestion to configure a browser like cache for resteasy clients; yet the proposed solution feels a bit "experimental" (delete whole cache if size too big, write to mailing list if other cache solutions should be supported) imo. In order to have some caching in place, I decided to manually cache the responses with quarkus application caching instead for now. It would be nice though, if this could be a core feature of quarkus.

rgmz commented 2 years ago

Quick googling suggests that vertx http client doesn't support it but it needs to be verified.

Vert.x now has a CachingWebClient, with support for noop, local (ConcurrentHashMap), and shared by default.