The code used to power the Mewna Discord bot when it was alive. None of this is supported or will be maintained. There will never be a "do it yourself" guide or similar. You are not permitted to create a bot named "Mewna" with this code for any reason.
From testing it on a relatively-large (>30 recommended shards) bot, it seems that we're quite wasteful with RAM to an extent - wasting ~300MB of RAM that gets GC'd quite often
Sometimes - but only sometimes - when a shard disconnects, after it RESUMEs it will fail(?) at doing proper heartbeat detection and close the websocket connection, even if it isn't necessary to do so.
This isn't a big thing per se, just would be better for the end-user experience. Request latency should be factored into REST ratelimit reset time because the 500ms pause we currently use may be too {slow,fast} depending on a number of circumstances.
Currently, it returns messages in reverse chronological order. It may make more sense from an end-user's perspective to return them in chronological order instead.
Right now, the DefaultShardManager implementation is heavily dependent on knowing how shards work internally, which isn't ideal. We should provide a friendlier interface to this if at all possible.
This is more complicated than the existing ratelimiter tests, but is a good idea to make sure it works as expected without potentially spamming the API.
In some cases (eg. just listening on raw websocket events and doing something with them), it may be undesirable to waste cpu/memory on creating and firing events that won't be used ever.
In some cases, it is desirable that we recv. all the events from the gateway, and emit proper objects, but don't emit certain events. For example, I personally don't like PRESENCE_UPDATE and don't want to decode it to an object ever, but need it for cache updates.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent