dhilipsiva

yes - I will definitely be adding adding more Language specific files as soon as I find time.

No - It did not stall. The contributions graph are ONLY for commits on master branch. As you can switch to other branches - you can notice that they have 2k,3k or 4k commits ahead of master. Its being actively developed. But not much on master branch. Just on different branches. Mostly on `v4-dev` branch.

No - It did not stall. The contributions graph are ONLY for commits on master branch. As you can switch to other branches - you can notice that they have 2k,3k or 4k commits ahead of master. Its being actively developed. But not much on master branch. Just on different branches. Mostly on v4-dev branch.

It will certainly be non-blocking. But the primary libraries that we use to scan the apps is written in python. And we love python. So we went to python.

Yes we could have gone with either one. It would have worked for having both.

RabbitMQ is very reliable (At the cost of performance). It persists the data on disk. Even if the RabbitMQ server goes down, we can attach the disk onto a new instance ant it would restore to the previous state. We needed this for task queues. They should work no matter what.

Redis is much more performant (at the cost of reliability). Because, by default, everything happens in-memory. Without additional settings for persistence (Which will bring down performance), if the Redis instance goes down, then all data is lost. We needed the performance for quickest delivery of notifications. milli-seconds matter.

Plus, now we can scale tasks and notifications independent of each other.