Supervises shard processes.

Implementation

As events are sent to the shard, the following happens:

1. Shard looks to see what type of event it is, only dispatch events are sent to the producer.

2. If the event is a Dispatch, the payload is converted to an atom-keyed map. This is done because over ETF (which Nostrum uses), map keys are sometimes binaries and sometimes strings, making it a real headache. Additionally, with atom keys, we can use the Map.key notation. This is normally considered unsafe but a debug messages will be emitted if a key is unsafely converted to an atom. In this way we can ensure that our atom table is not growing unbounded.

3. The payload is then written to the cache. To make sure we're not overrunning the cache, especially at startup with request_guild_members or other heavy payloads, this is done in the shard itself.

4. The cache updates itself from the new data. In some cases, such as update or delete events, it may send out a second "old" object as well, that helps the library user to determine what changed.

5. After writing to the cache, the shard sends out the event after going through the cache to all subscribed processes. In general, the payload will often match the payload described by the official Discord API documentation.

6. The shard instructs the websocket client that it's ready to read more data. This prevents flooding the shard with messages that it may not be able to handle yet, thus growing the message queue and the memory usage.