Discordoo NPM | npm.io

WARNING

THIS LIBRARY IS UNDER DEVELOPMENT! Parts of the stuff described here is not done yet, and we are just planning to implement it.

About

Discordoo is a Discord API library interface. It was built from ground-up to provide better and faster APIs, both internal and external, than existing Node.js libraries offer.

Features

Very scalable in any way — inter-machines sharding (PLANNED IN 1.2), custom modules for events queue (someone should create an appropriate provider)
Really fast — this is not a promise, but real tests!
Convenient to development — we create predictable APIs and take care of the convenience of development
Caching policies — do not store a cache that your bot does not need (PLANNED IN 1.0)
Flexible in everything — you can replace parts of the library as you need using our providers (PLANNED IN 1.0)
Safe for large bots — global-rate-limit synchronization between shards on one machine (PLANNED IN 1.0), the ability to limit the number of events sent by gateway to your bot per second (PLANNED IN 1.3)
Convenient to monitor — any statistics, from v8 to events per second, are available for each sharding instance (PLANNED IN 1.2)
Good TypeScript support — the library written in TypeScript, so we naturally support integration with TypeScript well
Tested — critical components tested using various benchmarks, including testing using deep-monitoring systems like N|Solid

Let's start

Node.js v12.18 or newer required. 1. Installing 2. First code & starting

Benchmarks

While the library is under development, only Discordoo Collection Benchmarks are available.

Discord.js collection VS Discordoo collection

You can find these benchmarks here.

Planned features

Waifoo — a framework for creating discord bots based on Discordoo (commands, other features).
Kawaioo — a library / nestjs microservice that will allow you to interact with the Discordoo ShardingManager over TCP and UDP, to create your own scalable REST API for the bot.
Voice support — at this moment, the library does not support voice.
Microservices — injection of microservices into the Client that can communicate with each other.

Release milestone

A complete description of everything that must be in Discordoo to be released

Release deadline: When it's ready. I'm tired of trying to cram an unrealistic amount of work into a couple of days and make commits with 1000 lines at once. You can blame me for that, I understand this. Sorry.

please read this

Sharding

Implement sharding
Shards spawning
- use processes for shards
- use workers for shards
- use clusters for shards (unfortunately, windows not supported)
Shards communication
- Shards must be able to communicate in fast and scalable way
- Shards must use hello/identify algorithm
- Shards must use heartbeat algorithm
- Shards must be able to send, receive and handle CACHE_OPERATE messages
- Shards must be able to send errors to ShardingManager, manager must handle these errors
User-land APIs
- User must be able to spawn shards
- User must be able to restart specified shard(s)
- User must be able to destroy shard(s)
- User must be able to get shard(s) statistics
  - v8 statistics
  - custom statistics
  - events per gateway shard per second
  - common statistics (guilds in cache, users in cache, channels in cache, etc.)
- User-friendly sharding APIs in sharding instances

Gateway

Implement gateway
- Implement gateway provider
Connecting to gateway
Reconnecting/resuming in common/emergency cases
Receive and send etf encoded messages
Receive and decode zlib-compressed messages
Multi gateway shards support in one WebSocketManager instance
Processing events/s smoothing/limiting
Handling gateway rate limits
Send events to WebSocketManager, and then to GatewayProvider
Gateway must be able to restart only specified shard(s)

Rest

Implement rest
- Implement rest provider - rest request (like constructor) & rest provider (performs requests and handles rate-limits optionally)
Requests
- Sending requests to Discord
Responses
- Unified response form for library internals
Rate-limits
- Rest must smartly-handle rate-limits using remaining header
- Rest must synchronize global-rate-limit between shards on one machine

Cache

Implement cache
- Implement cache provider
Library must be able to store something
Library must be able to delete something from cache
Library must be able to check cache size
Library must be able to sweep cache
Library must be able to iterate cache
Library must be able to operate with cache in a different shards from one shard
Caching policies
- Cache must handle GlobalCachingPolicy
- Cache must handle MessagesCachingPolicy
- Cache must handle GuildsCachingPolicy
- Cache must handle GuildMembersCachingPolicy
- Cache must handle ThreadMembersCachingPolicy
- Cache must handle ChannelsCachingPolicy
- Cache must handle EmojisCachingPolicy
- Cache must handle RolesCachingPolicy
- Cache must handle PresencesCachingPolicy
- Cache must handle UsersCachingPolicy
- Cache must handle OverwritesCachingPolicy
- All the policies listed above must be able to handle custom caching functions

SID - still in development

Entities (discord structures)

Must be extendable
Anti monkey-patch defence
Implement Guilds
Implement Messages
Implement Channels (SID)
Implement Members
Implement Emojis
Implement Stickers
Implement Roles
Implement Presences
Implement Reactions
Implement Users

User-land APIs

Collection
Wrapper
BitField wrappers
Entities managers
- EntitiesManager
- EntitiesCacheManager
- GuildsManager (SID)
- ChannelMessagesManager/ClientMessagesManager (SID)
- GuildChannelsManager/ClientChannelsManager (SID)
- GuildEmojisManager/ClientEmojisManager (SID)
- GuildRolesManager/ClientRolesManager (SID)
- GuildPresencesManager/ClientPresencesManager
- GuildMembersManager/ClientGuildMembersManager (SID)
- ThreadMembersManager/ClientThreadMembersManager (SID)
- MessageReactionsManager/ClientReactionsManager
- UsersManager (SID)

Contributing

Feel free to create a PR, but check if there is an existing one. See Contributing Guide.

About license

We perfectly understand what the MIT license means. We will NOT do with our library the things like that happened with popular library colors. It is complete idiocy to hope for sufficient help by writing a couple of tweets, and not receiving it, bringing tens of thousands of dollars in losses to both companies and ordinary people. These people are not to blame for the fact that your library is licensed under MIT. If you need help, contact the appropriate authorities, and do not spoil people's lives because they did not help you when everything was bad for you.