Replies: 1 comment
-
I'm afraid this comment is conflating many different things, and there is a lot to unpack here. To start, I want to say that no parts of Rails have a hard dependency on Redis.
First and foremost, the licensing change only impact future versions of the Redis server. The current one will remain maintained as BSD license for quite a while, and you can most certainly expect a community fork that will be BSD licensed. Second, regardless of what I think the new Redis license, it has close to no impact on Rails users. The limitations applies to companies offering Redis as a service, little to no Rails users do that. It won't change anything for Rails users that simply installed Redis or are using a 3rd party Redis provider.
Yes, that's why you can certainly expect a community fork of Redis.
Sidekiq didn't "add support". Dragonfly, like KeyDB and others is wire compatible with Redis. There was no code change done in Sidekiq to support Dragonfly and you can likely run a 10 years old version of Dragonfly again any of the Redis compatible databases.
Again. No need. They are wire compatible, just like MySQL and MariaDB are. Some commands may be missing, but the various Rails pieces that use Redis only use very common commands that (unless I'm mistaken) are supported by all the forks and alternatives. All this to say there is no reason to panic, nor to rename anything nor to add any abstraction layers. Redis as a protocol will remain usable with a BSD license for the years to come, even if the server implementation will likely have another name, just like MariaDB. |
Beta Was this translation helpful? Give feedback.
-
With the recent change in licensing at Redis, I think it is time to question how Redis support in Rails should evolve. Yes, there is a philosophical part to it about software freedom, licensing and sustainable open source development. But here I want to focus on the more practical aspects.
The direction of Rails is to not rely on Redis as much as it did in the past, moving the default for everything from caching, job queues as well as ActionCable from Redis to the database. Still, I know very few Rails applications that are currently not using Redis.
I don't have any data on it, but I would assume that a high percentage of Rails deployments either user AWS Elasticache for Redis or Heroku Redis (Azure Cache for Redis, Google Cloud Memorystore for Redis, DigitalOcean Managed Database for Redis...). From my understanding, at the current point, all of these are just Redis in a trench coat. But due to the license change they will need to find a solution, like forking Redis, to keep providing that service.
Independent of that, there are alternatives to Redis emerging. Sidekiq recently added official support for Dragonfly in addition to their long-standing Redis support. From my understanding, that was not because of licensing (Dragonfly uses the Business Source License for a while, which is very similar to the Server Side Public License that Redis switched to), but because of performance. And there are Redis forks like KeyDB or Redict which keep a free software license.
For me, this raises the question: How compatible will all these solutions (from the hosted solutions of the cloud providers to the Redis alternatives) be in two years?
Maybe it is time to treat the data structure server the same way we treat the database in Rails: Have a library like ActiveRecord that people use directly, and ask people to install a driver for the one they chose. And, as in ActiveRecord, the abstract library might need to have different implementations for certain features between the data stores in the future.
@byroot already has split the
redis
gem that is used in Rails into the high-levelredis
gem and the low-levelredis-client
(andhiredis-client
) library. Maybe it is time to rename theredis
gem to something like ActiveDSS (data structure server) or ActiveHash 😉 The interface that byroot found for redis-client works for all the alternatives.Beta Was this translation helpful? Give feedback.
All reactions