Quetza │ 
Awesome Discord bot that performs various duties on my server.
Architecture
At its core Quetza is simply a user-client with a logger.
Modules
Modules define the features of Quetza.
🗂 The structure of a module
modules/example/
├ module.ts
├ commands/
│ ├ [command-name].ts
├ events/
│ ├ [event-name].ts
├ lib/
│ ├ [...libraries] // Including controller if exists.
module.ts
The module must have a definition file that adheres to the following interface as export.
📐 Module export interface [defined in src/lib/types.ts]
interface Module {
name: string; // Name of the module.
description?: string; // Description of the module.
controller?: unknown;
// The service orchestrating the module. (passed as third argument to command or event executor)
}
commands/[command-name].ts
Each command has to be defined in its own file, preferably named after the command itself. The client indexes the commands of each module and sends them to the Discord API.
📐 Command interface to export [defined in src/lib/types.ts]
interface Command {
data: ApplicationCommandData; // Definition of command specifically for the Discord API.
execute: (client: Client, interaction: CommandInteraction, controller?: unknown) => Promise<void>;
// Function that will be called upon interaction invocation.
}
⚠️ Each command must comply with the command interaction requirements of the Discord API.
events/[event-name].ts
Events are pre-defined by the Discord API and can only have new functions bound to them by modules, despite being declared similarly to commands.
📐 Event interface to export [defined in src/lib/types.ts]
export interface Event {
name: string;
execute: (client: Client, eventee: unknown[], controller?: unknown) => Promise<void>;
}
✅ These can be re-defined so that they can operate independently in their own module.
lib/[...libraries] & controller
If you expand the provided module structure, it will still be a valid module. lib/ is simply a suggestion to add consistency to the codebase.
The controller is responsible for orchestrating the behaviour of your module. Imagine it like a web application service.
📘 For example, creating players for listening to music on voice channels
Build System
Quetza relies on various dependencies to function correctly. The package.json file lists the engines, toolchain, dependencies, and other metadata.
⚠️ pnpm is being used as package manager.
External Dependencies
Modules (or maybe Quetza itself) can leverage external binaries that shall be located at bin/ directory or be accessible from the environment.
🔗 Listing of extenal dependencies
| Base/Module | Dependency |
|---|---|
| Music | yt-dlp |
Shipping
Docker
The primary method of deploying Quetza is through a Docker Image provided by the respective action.
docker run \
-e DISCORD_TOKEN=*aquired via Discord Developer Portal* \
--name quetza -d \
unknowableshade/quetza-bot:latest
From Source
Although it is possible to run it directly from the source, some additional steps are required.
- Compile TypeScript
pnpm run build
- Run Quetza
pnpm start
Environment
In any case, you have to provide environmental variables for bot to run.
- DISCORD_TOKEN: generated token issued by Discord itself at Developer Portal.
Licence
Quetza's source code is licensed under the MIT Licence.
Notice! This does not cover 'Quetza' branding such as logo or other assets listed, as these are protected by the separate licence.
