Redis cluster mode

[mbaumgartl]

Is your feature request related to a problem? Please describe. We're running a Redis cluster in production. With the current implementation it's not possible to pass an appropriate configuration to the RedisStore class to run it in cluster mode.

Describe the solution you'd like For our use case it would be sufficient if RedisStore constructor would also accept an instance of Predis\Client class. But this will expose an implementation detail. Predis doesn't seem be maintained anymore and switching Redis implementation would require a new major release.

For the future I would like to see a generic PSR-6 implementation in tus-php.

Describe alternatives you've considered We also run a couple of web servers, so the Redis cache seems to be the only possible solution at the moment.

[ankitpokhrel]

Hi @mbaumgartl this is a valid concern and relying totally on one particular redis client is not ideal. I would see if I can work on this anytime soon.

PRs are always welcome ;)

[mbaumgartl]

I was looking at changes needed to use custom cache backends in this library.

I would like to make some changes to constructor interfaces to allow dependency inversion.

pro

• easier testing (less/no mocking)
• long term maintainability (use abstractions instead of implementations)

con

• harder to use

@ankitpokhrel: Before I start the refactoring: How open are you to such major/breaking changes?

[ankitpokhrel]

Hi @mbaumgartl, Thank you for your interest in contributing to this topic :)

To be honest, I would prefer to have a non-breaking change for now. I think there can be 3 approaches:

1. We can either work on a new design in a separate namespace so that two implementation exists side by side for some time. Once the new implementation is ready, we can mark the old one as deprecated and remove it in the next major release.

2. Or, if passing new parameters to the already available methods is the main bottleneck of the current implementation, we can do a small hack using func_get_arg like in Symfony packages to keep the changes backwards compatible.

3. Another better option is to move to PSR-6/PSR-16 compatible cache implementation.

I would suggest going with the approach that could achieve the end goal with minimal changes.

[mbaumgartl]

Hi @ankitpokhrel!

I understand your concerns about introducing breaking changes. In general I want to move the architecture to use dependency inversion (it's impossible w/o breaking changes). In my opinion it's necessary to bring the project to the next level and reduce longterm maintainability.

I didn't look into the code in detail but that's a first blueprint of what I'd like to change:

<?php
namespace TusPhp;

use Psr\Cache\CacheItemPoolInterface;

class MetaCache
{
    /** @var CacheItemPoolInterface */
    private $cache;

    public function __construct(CacheItemPoolInterface $cache, int $ttl, string $prefix = 'tus_')
    {
        // ...
    }

    public function get(string $key)
    {
    }

    public function set(string $key, $value) : void
    {
    }

    public function delete(string $key) : void
    {
    }

    public function deleteAll(): void
    {
    }
}

<?php
namespace TusPhp\Tus;

use TusPhp\MetaCache;

class Server extends AbstractTus
{
    /** @var MetaCache */
    private $cache;

    public function __construct(MetaCache $cache/* .... */) // inject PSR-17 factories
    {
        $this->cache = $cache;
        // ...
    }
}

<?php
namespace TusPhp\Tus;

use Psr\Http\Client\ClientInterface as HttpClient;
use TusPhp\MetaCache;

class Client extends AbstractTus
{
    /** @var HttpClient */
    private $httpClient;

    /** @var MetaCache */
    private $cache;

    public function __construct(HttpClient $httpClient, MetaCache $cache, ClientOptions $options)
    {
        $this->httpClient = $httpClient;
        $this->cache = $cache;
        // ...
    }
}

I'm aware that these would be major changes to your project. And I would also understand if you decide to refuse making these changes now. I just want to know in advance before start working on a (big) pull request.

Regards, Marco

[ankitpokhrel]

Hi @mbaumgartl,

Apologies for the late response!

We are planning a next major release, and this change would be perfect for v3. The targeted min PHP version is 8, and there is a dev build available for you to start quickly with PHP8.

In case you are still up to work on this change, we would be happy to review and assist with the PR. There is no release date as of now, but we will hopefully be able to release it by mid/late next year if everything goes right.

Best Regards, Ankit

[mbaumgartl]

Hello @ankitpokhrel!

I didn't have much time to work on this issue lately. Although I was unsure about how open you are to these changes. I'm glad to hear you want to switch the cache layer implementation to PHP standards recommendation :+1:

What do you think about throwing some more PSRs at this project?

• PSR-18 - make HTTP client configurable
• PSR-7 / PSR-15 - replace symfony/http-foundation
• PSR-14 - make symfony/event-dispatcher configurable

I would like to this project moving to PSR-7/PSR-15 and PSR-18 in the future.

Good idea or too much for v3? :wink:

Regards, Marco

[ankitpokhrel]

Hi @mbaumgartl,

All of these changes sound tempting and are nice to have, but today's best practices can easily be tomorrow’s anti-pattern. So, IMHO we should not change anything unless it is absolutely required.

It would be better to spend time working on a feature that provides additional value to the library users moving forward. For instance: possible speed improvements, proper integration with cloud providers, etc.

Regards, Ankit

[renepardon]

What's the current state of php-redis instead of predis as mentioned in #289

[kellerjmrtn]

Bumping this issue as mentioned in #289 and #321. I noticed this is the only package in my laravel project still requiring predis/predis, as I use phpredis instead. Not sure if this is still an intended change