Update documentation

Author: Will Nelson

docs/gateway.md

@@ -9,12 +9,15 @@ ratelimiting, and sharding and outputs a continuous stream of events to your app
 
 ## Config
 
-The Spectacles Gateway has a variety of configuration options, but there are only 2 values that
-you *must* provide for the Gateway to work: your bot token and a list of events to publish.
+The Spectacles Gateway has a variety of configuration options, but there are only 3 values that
+you *must* provide for the Gateway to work: your bot token, a list of
+[events](https://discord.com/developers/docs/topics/gateway#event-names) to publish, and
+[intents](https://discord.com/developers/docs/topics/gateway#gateway-intents).
 
 ```toml
-token = "" # Discord token
-events = [] # array of gateway event names to publish
+token = ""
+events = ["GUILD_CREATE"]
+intents = ["GUILD"]
 ```
 
 By default, the Gateway reads its config file from `gateway.toml` in the current working directory.
@@ -25,25 +28,22 @@ You can also specify this config using environment variables.
 
 - `DISCORD_TOKEN`: your token
 - `DISCORD_EVENTS`: comma-separated string of gateway event names
-
-### Gateway event names
-
-Gateway events are documented on the [Discord API documentation](https://discord.com/developers/docs/topics/gateway#event-names).
+- `DISCORD_INTENTS`: comma-separated string of intents
 
 ## Standard IO
 
 By default, the Gateway simply outputs to standard output. If you'd like to run a quick test,
 here's a Docker command you can run to see incoming `MESSAGE_CREATE` events.
 
 ```
-docker run --rm -it \
-	--name gateway \
-	-e DISCORD_TOKEN="your token" \
-	-e DISCORD_EVENTS=MESSAGE_CREATE \
+docker run --rm -it
+	-e DISCORD_TOKEN="your token"
+	-e DISCORD_EVENTS=MESSAGE_CREATE
+	-e DISCORD_INTENTS=GUILD,GUILD_MESSAGES
 	spectacles/gateway
 ```
 
-You can even publish data *back* to the gateway if you input JSON to the terminal.
+You can even publish data *back* to the gateway if you input MessagePack to the terminal.
 
 This is the JSON format used when using the STDIO mode of the gateway. `event`
 is mapped to the `t` property and `data` is mapped to the `d` property of a
@@ -56,16 +56,42 @@ is mapped to the `t` property and `data` is mapped to the `d` property of a
 }
 ```
 
+## Redis
+
+Change your config to specify Redis as the broker type and provide Redis connection options.
+
+```toml
+# base config here
+
+[broker]
+type = "redis"
+
+[redis]
+url = "localhost:6379"
+```
+
+You can now consume events from this Redis instance. To verify that this is working, simply execute
+`XREAD STREAMS {event_name} 0-0` on Redis, where `{event_name}` is replaced with a Discord event
+you are expecting (e.g. GUILD_CREATE).
+
+You can also change the shard store to Redis. This will allow your gateway sessions to persist past
+restarts in case your gateway dies.
+
+```toml
+[shard_store]
+type = "redis"
+prefix = "gateway"
+```
+
 ## AMQP
 
-Most of the time, you'll want to use a proper message broker for getting data from the Gateway to
-your applications. Change your config to specify AMQP as the broker type by adding the TOML below.
+Change your config to specify AMQP as the broker type and provide AMQP connection options.
 
 ```toml
+# base config here
+
 [broker]
 type = "amqp"
-group = "gateway"
-message_timeout = "2m"
 
 [amqp]
 url = "amqp://localhost"

docs/introduction.md

@@ -4,21 +4,19 @@ id: introduction
 title: Introduction
 ---
 
-Spectacles is a collection of applications and libraries designed to help you make stable,
-microservice-oriented Discord bots.
+Spectacles is a distributed Discord bot framework.
 
 ![Architecture](../static/img/architecture.svg)
 
 A basic Spectacles bot runs 4 services:
 
 1. Gateway
 2. Proxy
-3. RabbitMQ
+3. Message broker
 4. Command handler
 
-The Spectacles organization provides the gateway and proxy services. RabbitMQ is developed
-independently. You are responsible for writing your own command handler (that's why you're here,
-afterall).
+The Spectacles organization provides the gateway and proxy services. You are responsible for
+writing your own command handler (that's why you're here, after all).
 
 Each of these services is fully stateless and can be easily scaled up or down across machines.
 
@@ -33,24 +31,30 @@ gateway:
 - Reconnection
 - Gateway ratelimits
 
+[More info](gateway)
+
 ## Proxy
 
 The proxy is responsible for handling all of the outgoing HTTP requests to Discord. It ensures that
 your bot complies with Discord's ratelimits under any circumstance. Eventually, the proxy will also
 cache data and ensure that you never run into a performance bottleneck while fetching Discord data
 in your application.
 
-Your applications publish requests to RabbitMQ. The proxy consumes these and sends them to
-Discord as soon as possible. The proxy is responsible for:
+Your applications publish requests to the message broker. The proxy consumes these and sends them
+to Discord as soon as possible. The proxy is responsible for:
 
 - HTTP ratelimits
 - Caching (soon)
 
-## RabbitMQ
+## Message Broker
+
+Spectacles supports 2 message broker options:
+
+1. Redis
+2. RabbitMQ
 
-RabbitMQ is a message broker that Spectacles relies on to consistently deliver messages to each
-service. You don't need to know how it works or how to use it, only that it's responsible for
-delivering messages between your applications.
+We recommend Redis, since it is generally more performant and you will need to use it with the
+gateway and proxy.
 
 ## Command Handler