Creating a Redis Module in 15 Lines of Code
gist.github.com
gist.github.com
Redis is such a well-written C software that I can't help but think modules might become an antipattern to Redis. I like the idea that the option to use modules exists, but I hope it doesn't spiral into dependency hell as it is with the Ruby ecosystem. I hope library developers think very hard before employing and requiring a module.
Redis is fast, easy to use, and extremely flexible, and makes it easy to use any of the hosted options (Redis Labs, RedisToGo). Its allure is that Redis is batteries-included yet small enough like a Swiss knife. I wouldn't mind installing a module if it brought in significant optimization for a specific use case. I personally hope most library developers will pretend modules don't exist, and that only app developers will use them. I have this selfish desire that most libraries stick to the vanilla Redis features, because for most things you can use app code to manipulate the features you need without modifying Redis and compromising performance. Modules might add to the heap of things to think about, such as special Redis deployments or the things that can go wrong with the module code.
My fear is that instead of years of using the simple Lego blocks that is vanilla Redis, modules will start a pattern where we need to install special modules to use certain libraries.
TL;DR, I'm worried for the potential for abuse with Redis modules. My love for Redis was how simple and powerful it is, and yet now Redis has grown up, ready for modules.
I think C is both a blessing and a curse. The challenge of using C correctly has led to memory leaks, remote code execution, segfaults, etc. I'd use Go if it's possible to write Redis modules.
I'm more interested though to see when a JS module wrapper gets implemented.
I understand the concern, but if it ends up being half as flexible (and I already love me some Redis) I can only see good things.
1. There will never be a way to install modules automatically provided by the Redis OSS project. The use case is to grab a few modules you may need for vertical use cases that are otherwise not cover, so you just don't install a number of modules depending on other modules and so forth.
2. I'll not write modules but will care about exporting a good modules interface. What I believe has to be done, will be implemented inside the Redis core, not outside. SO it's totally a community thing. For the project itself is like: "we are going to give you this possibility, so that the fact the core is conservative about what functions to add, does not block you". But the model for Redis does not change, Redis is what we provide in the core. I work only on core stuff. The site only documents what we have in the core.
3. I'm not going to debug for hours or days crashes happening with modules loaded. On crash the list of modules installed will be reported in the crash trace.
So modules are going to be a good addition and there will be use cases that can be solved very well with modules, but are not going to change what Redis is. It's up to the user if to use Redis "core", or if to leverage modules. Wise users will pick modules when needed, and will inspect modules for quality and fit. Unwise users will install a lot of garbage, then eventually say Redis is a shit. But this is how the world works :-)
We're using redis as a queue (Sidekiq) and also to store the index.html page for our SPA. We have an "active" key in redis and its value is the key for the current index.html. This let's us push new versions of our app into redis (each generation of our asset files has a unique name so a new index.html gives you a new version of the SPA). We can then add a get param to our URL and pull a specific version of the index.html out of redis. Once we've smoke tested, we update our "current" value to point to the new index.html and, boom, zero downtime deploys.
What's your story?
Also what encryption algorithm are you using on your cookies. I ask because certain algorithms produce malleable ciphertexts, which could potentially be a huge vulnerability.
Here's the highscalability writeup: http://highscalability.com/blog/2014/9/8/how-twitter-uses-re...
Then it can serve as an incubator before importing functions into the core library.
The only problem with modules is that poorly written modules may cause unstability. One way to mitigate this is to have some sort of fuzzer/stress tester for developers to test their modules against.
[1] Example: http://www.omanurkka.fi/files/test.c.txt
I don't see why you would hide a link to the official redis repo.
http://support.bitly.com/knowledgebase/articles/136551-can-i...
Usually I hate those titles too because they show some "import gravity" type of thing, but here the point was to just show that the boilerplate is roughly 15 LOC.
There are probably plenty more reasons I'm not thinking of ATM.
Exclaiming it only took 15 lines of code is mostly irrelevant.
[EDIT] - and to have the tutorial fit on a printed A4 page.