Redis Backplane for Hubots

Summary

Hubot Redis Backplane hubot-redis-backplane leverages Redis Streams to create a distributed backplane for Hubot. Hubot Consumer This module is a Hubot Adapter. If you npm install it, you would start a Hubot instance with -a @hubot-friends/hubot-redis-backplane and it will connect to Redis, create a Consumer Group and register itself as a Consumer to the specified Redis Stream (e.g. inbox) and "listen" for incoming messages. The term "Adapter" here is just the fact that this connection utlizes Hubot's Adapter design – technically speaking. So in this part of the setup, Redis Streams is the message input and the Hubot Consumer connects to a stream as it's source of messages. At this point, it does nothing until messages are added to the inbox stream. Note. You could add messages manually via the Redis CLI if you wanted and the Hubot Consumer would process those messages and add it's response to a Redis Stream – outbox. Referring to the right side of the diagram below, we've started a Hubot Consumer # 1, part of a Redis Consumer Group. There can be multiple Consumer Groups. I think of a Consumer Group as providing a set of functionality. You'll typlically just have a single Consumer Group where all the Hubot Consumers come from a single codebase, but have different "consumer ids". I'm sure we could go crazy here with scaling functionality out with multiple Consumer Groups. But let's try to keep things simple first before we jump to Hyperspace. Hubot Adapter (Adapter here refers to the adapter that connects to the chat app e.g. Discord, Slack, MS Teams) The next part of the design is the left side of the diagram above – the input. This Hubot instance's role is the adapter to the chat platoform (e.g. Slack, MS Teams, Discord). You'll still start this instance with something like hubot -a @hubot-friends/hubot-discord because the chat platform is how users interact with Hubot – the input. But now, this Hubot instance won't have all you're command handling scripts; it'll ha...