>
> Does this sound reasonable? Any guidance or completed projects that
> took a different approach to keep performance snappy and make the
> expensive GETs just-in-time?
>
What we do is to optimistically prefetch what we expect might be needed and
place it in a short-lived cache. Using a super-resource request as a trigger
for fetching sub-resource context seems to be a nice way to not stress the
database while reducing user-perceived wait-times.
If you use EhCache's SelfPopulatingCache you even get blocking behavior
handed to you so that the database is only ever hit once in spite of
multiple simultaneous requests (browsers tends to do that).
And since we're already pulling in EhCache, we also use
a SimpleCachingHeadersPageCachingFilter in front and boost performance due
to support of conditional GET etc. I suppose the benefits of these caching
schemes all depends on your view on stale data.