How to cache JSON responses

[Marcel Stör]

In a previous post it was asked what cache to use
<https://groups.google.com/d/msg/dropwizard-user/CsWsXtCjDYs/6x24u4ea1B4J>.
The discussion was mainly about "application-level" caches.

I'm interested in caching the JSON responses serialized by Jackson and sent
by Jersey. It'd be tremendously helpful to be able to place @Cache-like
annotations on resource methods like so (borrowed from Play! framework)

@GET
@Timed
@Cached(key = "list", duration = 60)
public Collection<Foo> list()

I know I can solve this on infrastructure level (e.g. Varnish, Squid) but
since Dropwizard offers such a self-contained package I was wondering
whether there are means to achieve what I'm after.

[Jochen Schalanda]

Hi Marcel,

Dropwizard currently doesn't explicitly support JSR 107-like [1] or
similar annotations for caching HTTP responses out of the box.

You can, however, use the @CacheControl annotation [2] to generate a
HTTP/1.1 Cache-Control header [3] in your resource classes. This would
tell HTTP/1.1 clients how to cache responses but not cache anything by
itself.

There are currently no specific plans to add the necessary plumbing but
as always: Feature requests and (even more so) pull requests are welcome. :)


[1]: https://jcp.org/en/jsr/detail?id=107
[2]: http://dropwizard.io/0.7.1/docs/manual/core.html#caching
[3]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9


Cheers,
Jochen

Post by Marcel Stör
In a previous post it was asked what cache to use
<https://groups.google.com/d/msg/dropwizard-user/CsWsXtCjDYs/6x24u4ea1B4J>.
The discussion was mainly about "application-level" caches.
I'm interested in caching the JSON responses serialized by Jackson and
sent by Jersey. It'd be tremendously helpful to be able to place
@Cache-like annotations on resource methods like so (borrowed from Play!
framework)
@GET
@Timed
@Cached(key = "list", duration = 60)
public Collection<Foo> list()
I know I can solve this on infrastructure level (e.g. Varnish, Squid)
but since Dropwizard offers such a self-contained package I was
wondering whether there are means to achieve what I'm after.
--
You received this message because you are subscribed to the Google
Groups "dropwizard-user" group.
To unsubscribe from this group and stop receiving emails from it, send
For more options, visit https://groups.google.com/d/optout.

[Marcel Stör]

Post by Jochen Schalanda
Hi Marcel,
Dropwizard currently doesn't explicitly support JSR 107-like [1] or
similar annotations for caching HTTP responses out of the box.

Ok, I was afraid that this would be the answer. I currently see two
options for response caching, please let me know if there are reasonable
alternatives:
a) introduce Spring because it offers a nice caching abstraction which
supports annotations
b) use a Servlet filter
-- SimplePageCachingFilter from Ehcache[1] which is quite nice (used it
in the past for JEE apps)
-- ResponseCacheFilter from Guava webutilities[2] because I already use
a Guave cache for other cases

@CacheControl is nice and important but IMO it serves a different
purpose. It's helpful for long-lived resources (a few days I'd say) or
static assets as it improves the snappiness of a UI. However, I have
short-lived resources (1 minute) and by caching the response I'd reduce
load on the server.
This is not a case of premature optimization, I'm just experimenting
with DW. I quite like what I've seen so far.

Cheers,
Marcel

[1] http://www.ehcache.org/documentation/user-guide/web-caching
[2] https://code.google.com/p/webutilities/wiki/ResponseCacheFilter

[Corum, Michael]

Drop wizard includes Guava. I use that for caching. Not exactly what you are asking for but gets the job done.



Sent from Mike's phone

Post by Jochen Schalanda
Hi Marcel,
Dropwizard currently doesn't explicitly support JSR 107-like [1] or
similar annotations for caching HTTP responses out of the box.

a) introduce Spring because it offers a nice caching abstraction which supports annotations
b) use a Servlet filter
-- SimplePageCachingFilter from Ehcache[1] which is quite nice (used it in the past for JEE apps)
-- ResponseCacheFilter from Guava webutilities[2] because I already use a Guave cache for other cases
@CacheControl is nice and important but IMO it serves a different purpose. It's helpful for long-lived resources (a few days I'd say) or static assets as it improves the snappiness of a UI. However, I have short-lived resources (1 minute) and by caching the response I'd reduce load on the server.
This is not a case of premature optimization, I'm just experimenting with DW. I quite like what I've seen so far.
Cheers,
Marcel
[1] http://www.ehcache.org/documentation/user-guide/web-caching
[2] https://code.google.com/p/webutilities/wiki/ResponseCacheFilter
--
Marcel Stör, http://frightanic.com
Couchsurfing: http://www.couchsurfing.com/people/marcelstoer
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
--
You received this message because you are subscribed to the Google Groups "dropwizard-user" group.
For more options, visit https://groups.google.com/d/optout.

[Marcel Stör]

Just to document my findings...

Post by Marcel Stör
b) use a Servlet filter
-- SimplePageCachingFilter from Ehcache[1] which is quite nice (used it
in the past for JEE apps)
-- ResponseCacheFilter from Guava webutilities[2] because I already use
a Guave cache for other cases

The integration is equally simple for both. For Ehcache you of course
need ehcache.xml in the classpath. I tested both and for my use cases
the Guava webutilities were quite a bit faster i.e. it resulted in
shorter response times.

If you add it to your pom.xml you can omit its transitive dependencies:
<dependency>
<groupId>com.googlecode.webutilities</groupId>
<artifactId>webutilities</artifactId>
<version>${webutilities.version}</version>
<!-- Dropwizard ships with all dependencies the webutilities need -->
<exclusions>
<exclusion>
<groupId>*</groupId>
<artifactId>*</artifactId>
</exclusion>
</exclusions>
</dependency>


Cheers,
Marcel