Estimated release date

[kpasokhi]

Hello, First of all I was looking for feathers redis support and wanted a simple redis adapter not a bloated ORM for redis. I found this repo by accident and wanted to thank you in advance for planning to implement a redis adapter. By the way I wanted to ask when is the estimated release date for this adapter?

Best regards.

[appurist]

Hi @kpasokhi and thanks for the interest. This project is brand-new, but as of the last 48 hours I'm well into it now.

It's not a lot of code but there have been several technical obstacles, as well as RL job demands getting in the way until now. Working through those now. I'm probably only about 50% done but as I said it's not a lot of code so I'm hoping to have something that passes all the standard Feathers db service tests in a couple of days. This will provide db-independence via a common Feathers interface.

However, that common Feathers interface will not let you take advantage of most of the Redis features, especially data types. After digging into it a bit, I'm a bit disappointed to find this will probably be best suited for someone with a project that already has existing code accessing another Feathers db service and wants to switch to Redis, or one where having an option to do that in the future is an important goal. For projects without complex data storage needs, and projects like caching services, this may be just fine and provide that db independence. If porting an existing Redis service, mapping the calls to this interface (create, find, get, update, patch, remove) outlined in the Services page may be challenging.

I've been back and forth in my mind over whether it makes sense to extend that common Feathers interface to support a wider Redis feature set, however I think the answer is that this would defeat the whole purpose of providing a feathers-redis; portability between db services. Anyone who wants more Redis probably should be using a more direct interface.

If you are happy with those 6 db operations, with some added support for Redis dbs (like a namespace prefix on ids/keys), then this may be appropriate and an early version as soon as a few days (or a week). But to be honest, if you're going with Redis and don't have a strong need for db-independent code, you may be better off just coding directly to node_redis anyway, since the interface there is not much more complicated than feathers-redis will be. However, this project will also give you is a consistent promise-based async implementation as well.

[kpasokhi]

Thanks for your reply, I should investigate more to decide.

[appurist]

FYI, I've been busy with my paying client work but also making slow but steady progress on feathers-redis. It's been much more complex than I had expected, due to Redis being so different from other databases. And the latest holdup has been with problems implementing a promise while loop. Redis was auto-promisified and I'm going to need to do manual wrappers I think in order to properly implement the while loop needed in find (Redis SCAN).

The problem is SCAN must be called an unknown number of times, each time using the result of the previous (async) invocation, with no expectation at all of how many items will be returned (it may even exceed the limit specified, or be 0), and no idea of how many times it's going to need to make an async operation call. So it's taking some Promises voodoo to get this right.

My advice is actually to just code to Redis directly. It is different enough that trying to force it into the standard interface is giving up most of the benefits of Redis without gaining the benefits of the Feathers service interface. In hindsight, they barely overlap.

You won't be able to use hash, set or other Redis types, and those developers choosing Redis over other dbs are probably doing so for serious production projects where the features are important. I probably will not be using feathers-redis for my own feathers projects on Redis.

I think feathers-redis will only really be useful for those feathers projects already coded to some DB (e.g. mongo) that must move to Redis, and as quickly as possible. It's a shortcut for those sites, and even in that case, they should probably replace the feathers-redis calls with direct calls, over time, and then be able to take advantage of the different feature set.

[daffl]

See discussion in https://github.com/feathersjs/feathers-redis/issues/4#issuecomment-306995921