The problem/use-case that the feature addresses
Redis is more and more popular, it's always strongly relied upon. It's diffcult to write test cases, if a project imports the Redis.
Description of the feature
I hope the Redis Team can provide the embedded Redis, which can mock all features of Redis when writing test cases.
Alternatives you've considered
- The embedded Redis should be independent of any operating system
- The embedded Redis should be independent of whether the user has installed Redis or not
Additional information
There are some implementation of embeded Redis in github, such as kstyrc/embedded-redis. However, all of them are based on Redis 2.8.19, which cannot support Apple M1 Chip( If you want support it, Redis need to upgrade to6.0.10 or 6.2 RC2, see #8062, #8195)
The codemonstur/embedded-redis has tried to update Redis to 6.X, but they cannot get the source for binaries. see #6 and #7
Also, see #7421
I really hope Redis Team can provide a solution to solve this problem.
Comment From: yossigo
Have experimented with something similar in the past as well.
Comment From: codemonstur
Another project that attempts the same: https://github.com/tonivade/claudb. I got it to work a bit but it's implementation isn't 100%. And its missing features wrt the real thing.
Comment From: itamarhaber
There seems to be a definite interest in this and lots of potential value. While embedding wasn't in the scope of this project, historically, it would make sense to revisit that. IIRC, @yossigo's experiment was quite promising but the real pickle was around the request/reply efficiency. While a less-than-efficient embedded Redis may be great for testing, the question is whether it should also be considered as something more than a development/testing tool.
Comment From: MoFHeka
Maybe an embedded Redis would be good way to implemente redis side cache? @yossigo @itamarhaber
Comment From: yossigo
@MoFHeka I assume you mean client side caching? When we discussed this in the past, the general consensus was that this is best done in a form that is native to the application thus trying to share client-side code across different clients is not very practical.
Comment From: MoFHeka
@yossigo But if we have an embedded Redis library, it's easy to keep the same data structure(for example hash key) both in servers and clients side. Even this embedded library could load Redis module, that will keep all things in Redis ecosystem. All we need is just a Redis service dynamic library.
Comment From: yossigo
@MoFHeka Your argument is correct (and was brought up), but the counter argument was that different clients (e.g. for Python, NodeJS, Java, etc.) would gain more by storing the native language object.
For example, a Python app uses a dict and stores it on the server using HMSET. If it's going to be using client side caching, it will rather keep track of this dict at the Python level and not in its Redis form inside an embedded Redis native shared library (which would require serialization / deserialization on every subsequent access).