mORMot Open Source

igors233

Member

Registered: 2012-09-10

Posts: 234

TMvcRendererCachePolicy

I think it would be useful to add cacheParamsWithSession that would combine caching with session data and parameters.

For example page could render different based on logged user (covered now with cacheRootWithSession) and based on logged user and parametars which is not covered right now.

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,220

Website

Re: TMvcRendererCachePolicy

Caching benefits if several clients/users are likely to retrieve the same exact content at the same time.
Whereas a session-customized page is for a single client/user only.
So it was not implemented because it was not worth it.
Caching such pages would sound like premature optimization to me.

If was not implemented because cache was meant for static pages, not for session-customized pages.
And it would be much more complex to handle several versions of the same page depending on the session.

I doubt there would be a great performance benefit, since a single user would use the page.
The client already should receive a 304 NOT CHANGED code so avoid any transmission - which is likely to be more the bottleneck.

igors233

Member

Registered: 2012-09-10

Posts: 234

Re: TMvcRendererCachePolicy

On a similar note, TMVCRendererJson isn't cacheable by default while TMVCRendererFromViews.

Situation I have in practice is that I have server MVCApp that creates pages, fills it via mustache templates and it's then consumed by JS client.
JS client needs same data as server (taken from database or from some external API), it just does some additional handling with it.
Retrieving data depending on page (query) could take few seconds or more if it uses some external API. From client I'm getting data by calling same URL just with added /json param which makes MVC let it go through TMVCRendererJSON that does call same interface method as default page handler (without /json sufix). So in span of few second same method will be called twice (so twice DB call, and API call) and that's a perfect candidate for caching.

Rendering html based on json data is fast but creating that json data is slow so having caching in the first step would be quite usefull.
For example if inheritance order is changed here, make TMVCRendererJson a base and then inherit TMVCRendererFromViews from it.
That way database/API call that generates json could be cached and used several times either with different user/session or from both server that produces html page and js client that consumes raw json.

Alternative (or best both) would be to decouple TMVCRunOnRestServer.InternalRunOnRestServer from TMVCRendererJSON/TMVCRendererFromViews and allow app to specify inherited renderers for use here.