cache layer around get requets

[marcosh]

No description provided.

[maraspin]

Wondering what it would be best as an approach here... Implementation idea:

1. Adding a $app->pipe(CachingMiddleware::class); call after $app->pipeRoutingMiddleware(); in pipeline.php, so to "intercept" all GET requests and then act upon requested URL (either fetching data and creating a cached result; or returning the latter);

2. Store contents somewhere on the Filesystem (where shall I putt cached stuff?)

3. I came up with two ways to perform cache invalidation:
   a] at each call, we check for the last update time of cached result and invalidate it once a certain time interval has passed (pro: everything is self contained; cons: it'd never be a good approach for production)
   b] we have an external CLI script, to be invoked by cron (or by hand, in our context), which takes care of cleaning up old resources (cons: additional software, DRY violation (multiple places - framework and OS - to handle same thing); pros: additional way to interact with the framework to be shown at the workshop - IE the CLI; similar to something I'd use in production).
   Which one would be best in your opinion? Or do you think there could be other, better ways to handle this? Thanks for your support! :)

[marcosh]

random thoughts:

• I would rather act at a route level, instead of a pipeline one;
• caching must be done before (i.e. outside) dispatch
• I would choose the expiration time approach; way simpler for our actual purpose. We will mention that it's not good for production

[maraspin]

1. Why so? If we aim at catching all GET requests, it might make sense not to spread to many $app->pipe(CachingMiddleware::class); statements. Having an high Fan-In at the beginning easily allows us to become more specific when and if needed. I might be missing something in the big picture, though.

2. I was thinking about putting it before the $app->pipeDispatchMiddleware(); call. Just after $app->pipeRoutingMiddleware(); (so to know enought about the reuqest), but definitely before domain logic kicked in. At least that was the idea... Again I might have missed something and picked the wrong location, thinking to do the right thing

3. Agreed. Will follow this hint. And add a comment on code. Would feel umconfortable otherwise :)

[marcosh]

1. The reason is to keep the middleware very simple and give the user the possibility to decide which routes to cache easily (you maybe want to cache the lists, but not the details)
2. I didn't say you were wrong, I just said before dispatch, but certainly after routing

[maraspin]

Made a first implementation. I still need to fix a JSON formatting issue on cached responses. I'd also like to take configuration parameters (IE cached files path, expire time) out of factory class and into configuration files. Feel free to take a look at response-cache and let me know if you notice anything which not ought to be there. Tnx!