apcu cache

[pavarnos]

Hi. Forget how I stumbled across this, but it looks awesome! I can't see why it has had so few downloads on Packagist... it does everything you need right out of the box without a ton of overhead. Great stuff!

Are you accepting contributions? I'd write an apcu cache driver and middleware for thephpleague/oauth2-server if you are interested.

Do you have an idea when v2 will be ready (and how different it will be to v1.2)? I'm looking to start writing my api in the next week or so, but would wait if you plan to release soon. What impact will v2 have on the middleware and caching interfaces?

[ahinko]

Hi, I don't think that many know about this package since I haven't done anything to promote it yet. I'm waiting until version 2 is out before I try and make Phapi more know.

I would most definitely accept contributions. I was considering creating a middleware for handling authorization and I was planing to base it on thephpleague/oauth2-server but I decided to focus on version 2 and wait. So it would be very helpful if you want to contribute.

Version 2 will not be backward compatible with version 1.2. I'm planing to make version 2 based on middleware so many of the core functionality in version 1.2 will be moved to different middlewares. I don't have a release date set (this is something that I do on my spare time) but I'm hoping to release it soon. I would suggest that you wait for version 2 if you can.

I have the middleware foundation outlined and I'm currently implementing request and response classes based on the PSR-7 HTTP Message proposal. The interface for middleware will look like this:

interface Middleware {

    public function __invoke(Request $request, Response $response, callable $next = null);

}

I will commit and push the middleware interface with documentation as soon as I've implemented the Request and Response-classes.

I haven't decided what to do with the Cache interface. I was hoping to base it on the PSR-6 Cache proposal but since I have no idea when it will be finalized and accepted I'm not sure what to do yet. It hasn't been updated in 5 months. I think the options are to stick with the same interface as in version 1.2 or go with the PSR-6 proposal and hope that it doesn't change to much before its accepted.

[pavarnos]

Thanks for the quick reply. I like the middleware idea: it will make Phapi much more flexible / extensible.

There has been a lot of heated debate about PSR-6, which is maybe why the delay. Personally I think the CacheItemInterface adds unnecessary complexity. Your Cache interface is simple, obvious and works. I could easily see how to implement apcu and filesystem based caching.

A possible interim step for Phapi is to implement your Router class with no caching. Create a CachingRouter that decorates or inherits the basic Router. Then you are insulated from later changes (eg adopting PSR-6), and maybe it will make testing easier too?

[ahinko]

I agree, the middleware approach will make Phapi more flexible. That's the main reason why I started with version 2.

I'm not concerned about the internal usage of the cache interface. The router can always be updated without impact for the user/developer. What I'm concerned about is if users/developers implements their own middleware and use the cache functionality there or even in an endpoint(resources in version 1.2). I would have to bump the version number to 3 if it breaks backwards compatibility.

But at the same time, I also think parts of the PSR-6 draft is unnecessary and complex and we have no idea how and if there will be any major changes done before it's finalized and accepted.

I have some minor things on the to do list before I will take a look at the Cache interface so I will hopefully make a decision within the next couple of days but I'm leaning against making some minor updates to the current interface in version 1.2 and wait with PSR-6 support until its finalized and accepted.

[pavarnos]

all good. if you want a second opinion on anything, let me know. happy to help (via this issue, through commenting on diffs, by email etc)

[ahinko]

@pavarnos I've finally started looking at the cache interface for version 2 and I've changed my mind in a way. My initial plan was to wait for PSR-6 to be finalized but I realize that it might be a while.

Anyway, I have a question for you. What do you think about the current Cache interface Phapi has in version 1.2? Should something change?

I myself think it's mostly easy to use and understand. The only method I think needs some explanation is the connect() method. I believe that the application should continue to work even if there is a problem connecting to the cache. So I added the connect() method since it makes connection errors easier to handle. The connect() method should return true or false. If the class returns false, Phapi will create a new NullCache() that doesn't really do anything exempt returning false when trying to receiving something from the cache. By doing that the application will continue to work.

[pavarnos]

Hard to say without seeing the code that is going to call it. I like your idea of a graceful degradation.

In code I'm writing now, I mostly avoid error code return values (eg false on failure) and instead rely on exceptions because this allows me to return more information on the reason for the failure to the caller. It also means cleaner code because I'm not having to check return values all the time: i can just use a class and assume it has worked. So in your case above, I'd probably create the NullCache in the exception handler.

But that is all said without knowing how you plan to call it...

[ahinko]

Thanks for your input.

I later realized that the connect method isn't needed with the new approach in version 2 since Phapi is using a Dependency Injection Container for all configuration including the cache.

And I have no idea why I wasn't using exceptions since I usually do that, so I've changed it.

The cache interface for version 2:

• https://github.com/ahinko/phapi/blob/develop/src/Phapi/Contract/Cache.php

Commits with cache interface and implementations:

• https://github.com/ahinko/phapi/commit/195c41de7ee19cca2ae1164f5def22d6dad02614
• https://github.com/ahinko/phapi/commit/1951e8aaf1eac7604747f259eedd4eb2c18a83f2

[pavarnos]

looks good. clear and simple