Coldbox Template Caching for the Future

Description

As we look at porting a gigantic application to be entirely API- and VueJS-driven, we are looking at our caching solution.

Historically, we've done what I think everybody does, where we have an object cache and some logic in either our model or service layer that employs getOrSet to draw something either from the cache or from the database. There isn't really a better way to do it when you never know how your business objects are going to be used – whether in a handler, a service layer, by another part of the model, et cetera.

But the picture opens up quite a bit when you can make the assumption that every single object you have is going to get serialized into JSON. At that point, why should you care about caching just individual models in their native form when you can cache every possible memento, every complex assortment of multiple object types – everything, inside the template cache?

There are two drawbacks to the template cache as it stands now when looking at it from a 'whole API' perspective.

The first is that the Coldbox REST-HMVC template relies on aroundHandler and aroundHandler won't execute on a cached event. There is a workaround which is not bad and maybe even desirable, but bears some consideration. It makes your vanilla API request something like this:

The public-facing endpoint isn't cached, so you always get the BaseHandler plumbing, but the data portion is, and I don't have to mess around with business model-specific caching layers. It'd be simpler if I didn't need two events, but other than the overhead of running two coldbox events per API call, it's do-able.

The other issue is how to clear the event cache, because it means that my service layer has got to keep track of which API endpoints use it, and that's messy. I don't want to have to go track down all the relevant handlers in a postSave() interceptor to be able to call clearEvent() for specific events. I know I can match multiple events, or clear all events in a handler, but it would be cleaner still if I could do this:

Then I can arbitrarily define groups of routes whose caches I want to clear.

This is just my experience in a couple weeks of thinking about this problem, but the broader use case is having Coldbox as the primary cache facilitator, rather than just the mechanism to access custom logic in your business layer. What do you think?

Activity

Show:
Brad Wood
March 12, 2020, 9:25 PM

Not sure I follow. preProcess is an interception point, not a handler convention.

Samuel W. Knowlton
March 12, 2020, 9:33 PM

Sorry, I meant preHandler.

Brad Wood
March 12, 2020, 10:38 PM

Yes, you’d need to call super.preHandler in the child class or the parent wouldn’t run. Unless, of course, you wished to completely replace the functionality of the base class. But in the context of this discussion, I’m fairly sure that event caching bypasses all of that regardless.

Samuel W. Knowlton
March 13, 2020, 4:19 PM

You’re right - I’d mistaken the preProcess point firing for the preHandler running.

In order to use preProcess, I’d have to re-architect the whole aroundHandler into it, which doesn’t really seem worth doing.

Samuel W. Knowlton
June 10, 2020, 3:12 PM

Just to pick this up again: are action-level cache groups a possibility?

Assignee

Luis Majano

Reporter

Samuel W. Knowlton

Labels

None

Priority

Major
Configure