PSR-6 - caching

[Sam Minnée]

Hi everyone,

PSR-6 covers caching, and it's just gone into the Review stage, which means that it's potentially not too far off from being accepted.

The details of it are here:

https://github.com/php-fig/fig-standards/blob/master/proposed/cache-meta.md

https://github.com/php-fig/fig-standards/blob/master/proposed/cache.md

In general, I think it's worth us trying to adopt PSRs for future major releases of SilverStripe where we can, as it will seriously improve the ease with which developers can use SilverStripe alongside other projects. So, I think we should seriously consider replacing the back-end of SS_Cache with a PSR-6 compatible cache implementation. We can link to a default library and let people swap out the default library with another one using the Injector.

The cache API that it exposes is a bit more verbose than what we've previously used. The cache-meta.md URL provides a good run-down of why they've tried to go this way. However, it begs the question: do we want to expose PSR-6 style API across all modules, or wrap it in a simplified API? The problem with wrapping it in a simplified API is that we're preserving a piece of coupling that we could otherwise remove.

Alternatively, we could build some more effective idioms for accessing caches as a standalone class that takes a PSR-6 cacher as a dependency. For example, you may define a closure that is executed only on a cache-miss.

$result = $cacher->getCached('cache-key', function() use($x) {
  return $x->doSomethingHard();
});

I could imagine that a standalone library that provided a few of these kinds of idioms around a PSR-6 core would be quite handy. I'm not sure if there are projects like this out in the wild, or if we should kick one off. If one doesn't currently exist, my preference would be to start it as a standalone project with minimal dependencies, and link it into SilverStripe, rather than making it one among 100s of classes in silverstripe/framework.

As a further point, I've got no idea of which caching library would be best to use, and we'd want to research that. A robust library with minimal dependencies and a good number of back-end implementations would be ideal. It's possible that Zend is still the best option (although doctrine/cache seems very popular). We'd want to confirm whether the relevant library was planning on implementing PSR-6, and ideally, we'd incorporate it after they have done so.

So, a bunch of vague early-stage thoughts right now, but I thought it a good time to get discussion started. What do people think?

Thanks,

Sam

[Conrad Dobbs]

I think it's an awesome idea. The more PSR compliant SilverStripe becomes the better.

From experience the current cache implementation is difficult to work worth. I've had issues using custom backends as you can't set the custom naming (unless using a two level cache).

[Hamish Friedlander]

Without tags you can't invalidate just a section of the cache. Although only the file backend of Zend_Cache (or the two-level system) really supported that, and the Aggregate class that relied on it is deprecated.

The PSR-6 interface is quite wordy to use. It doesn't cover service configuration / discovery though, which is the only thing SS_Cache really does.

Hamish Friedlander | CTO
SilverStripe

[Marcus Nyeholt]

For a lib that is meant to reduce the amount of operations the interpreter executes, Zend_Cache library has always annoyed me by the amount of stuff it tries to do, to the point that I occasionally use my own old-rolled lib for some things. Using PSR should at least give some varying options moving forward, particularly for things that  can affect site performance. 

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

[Ingo Schommer]

With your $cacher->getCached('cache-key') example, presumably you'd still need to get a named pool to instantiate $cacher?

The notation saves the isHit() conditional, but in my opinion also makes it harder to understand. For example: Does the expensive operation closure write that cache key? Apart from exchangeable implementations, one advantage I see in the PSR standardisation is the reduced cognitive overhead in understanding new APIs.

So if you've worked with caching in one framework, you'll know how to write it in another framework.  Given the limited API surface, I don't feel too strongly on a lightweight API wrapper either way, just my 2 cents.

--

Ingo Schommer | Solutions Architect
SilverStripe (http://silverstripe.com)
Mobile: 0221601782
Skype: chillu23