-
-
Notifications
You must be signed in to change notification settings - Fork 1
Application Command Indexing
Nexus prioritizes performance, and to achieve this goal, we utilize command indexing. This indexing links command names, guild (server) identifiers (snowflake), and command identifiers (snowflake), allowing us to determine which handler should manage each event. An index is crucial for efficient event handling.
By default, we implement a basic in-memory index that gradually populates over time. This basic, in-memory index continually improves performance as the framework indexes events. However, for even greater performance, it's possible to employ a persisted index that doesn't clear itself after restarts.
Nexus recently introduced modularity to index stores, enabling developers to create their own custom index stores. To understand the change and how the framework selects event handlers, we recommend reading Pull Request #8 first. In essence, an index store is a storage facility capable of storing the following data:
data class NexusMetaIndex(val command: String, val applicationCommandId: Long, val server: Long?)
To craft your own index store, you need to implement the IndexStore
interface. Refer to our implementation of InMemoryIndexStore
as an example. Once your index store is ready, instruct Nexus to utilize it with the following line:
Nexus.commandManager.indexStore = <your index store>
Afterward, the framework will populate your index store with indexes during command synchronization or explicit indexing. If you wish to manually trigger indexing, either synchronize the commands or use the CommandManager
:
Nexus.commandManager.index()
All information in this wiki was written during v1.2.0
, we recommend updating to that version if you are below, or creating an issue in GitHub, updating the wiki if the current information is missing, outdated or lacking.
To get started with Nexus, we recommend reading the following in chronological:
- Installation & Preparing Nexus
- Designing Commands
- Command Interceptors
- Additional Features (Subcommand Router, Option Validation)
- Context Menus
- Command Synchronization
You may want to read a specific part of handling command and middleware responses:
You can also read about additional features of Nexus:
- Subcommand Routing
- Option Validation
- Express Way (shard management)
- Inheritance
- Feather Pagination
- Nexus.R
You can read about synchronizing commands to Discord:
For more additional performance:
Additional configurations: