feat: added @discordjs/sharder
#8859
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ |
|
|
||
| public readonly spawnOptions: Required<ShardSpawnOptions>; | ||
|
|
||
| public readonly channels: IChannel[] = []; |
There was a problem hiding this comment.
Perhaps we could choose another less conflicting name for IChannel & <ShardManager>.channels, it could be confused with traditional Discord channels, perhaps this is something to consider? Unless the fact that it's internal allows us to override this non-ambiguity rule?
There was a problem hiding this comment.
It's called channel because it's the... channel strategy both the manager and the clients use to communicate.
There was a problem hiding this comment.
Before the class that managed the shard like this (manager side) was called "shard", that why I was hesitant about this new name.
There was a problem hiding this comment.
You said that, they're shards. But that's just djs's ShardingManager being too limited. Also, they're literally shards, and the way it instantiates shards is fixed by child_process.fork or worker_threads.spawn. Furthermore, they held a lot of Discord shard state.
Here, they're not just a single shard, but clusters of shards, they don't keep track of Discord shard state (in fact they're agnostic, this library can even be used for other libraries such as Eris, or even in stacks that have no relationship with Discord at all). And those clusters of shards are just the IDs, the classes' purpose is to define what's the way of communicating with the client, which is basically:
- ITC (inter-thread communication,
worker_threads) - IPC (inter-process communication,
child_process.fork/cluster.fork) - TCP (over network,
ws/http(s)/http2/quic) - RPC (over network, gRPC)
- Other (Redis streams, RabbitMQ)
Similarly, those keep the same analogy and are ported to the opposite direction, so basically something like this:
flowchart LR
A[ShardManager]
subgraph clients
B[ShardClient]
C[ShardClient]
D[ShardClient]
end
A <-->|Channel| B
A <-->|Channel| C
A <-->|Channel| D
There needs to be an opposite for the ShardManager --> ShardClient, while manager.shards may be somewhat accurate, client.shard (for ShardClient --> ShardManager) wouldn't. Furthermore, the "shard" is at the process where client lies on, it's not on client nor is client.
That's why I chose the name "channel". I understand it may be confusing for some users, but also keep in mind that sharder has no relationship with Discord, and instead, channels refer to the channel on which messages are sent.
It also makes a great analogy with real life, here we're using GitHub as a channel to communicate, but we could also be using Discord, or phones, or pigeons, or we could fly somewhere and talk face to face; the end result is always the same, the means we use to communicate is called a "communication channel", here, IChannel isn't that different.
Please describe the changes this PR makes and why it should be merged:
Supersedes #7204, implements part of #8084.
For more information about this sharder's architecture, please refer to the aforementioned RFC issue.
Features
Gzip(will not be included in initial PR)Brotli(will not be included in initial PR)ShardManagerProxy(will not be included in initial PR)Status and versioning classification: