clawcastle / sound-boart Goto Github PK

Make a simple search function that allows for searching for sounds that contain a certain string in their name. Could be used somewhat like this:

$find query_string

The ReadMe should be updated with the following:

• Information about how to use the bot. Basically the same content as the "help" command.
• Link to add the bot to ones server

Write logs to a file instead of just using console.log, since they disappear every time the app is deployed.

Use a proper database (either Postgres or Sqlite) for storing metadata like usage metrics and other configuration, rather than having to read an entire json file into memory every time.

Simply make it possible to run the bot using Typescript.

Enable changing the prefix for triggering the bot.

Right now there is some pretty strange behavior whenever the bot is deployed, where multiple instances seem to be running even though the container gets killed. I think this is because the Discord client isn't properly disposed when the process exits.

docker-compose would be nice for easily using volume mounts locally.

The help command isn't up to date as it doesn't contain information about all commands. It also doesn't take custom prefix into account.

Right now, the getCommandParts function is probably the one that is called the most often in the entire application, as it is invoked multiple times for each command. It could easily be memoized to greatly reduce the amount of string arrays allocated.

Right now the only option for storing the sounds is Azure Blob Storage. The files should just be placed in a configurable location on disk, which could then potentially be a volume mount.

All command aliases should be reserved so users don't accidentally overwrite them by uploading a sound by the same name.

Play a random sound

Records amount of times a sound is played. Deliberately doesn't record from playing greeting sounds.

Right now the sound files are only stored on the disk connected to the machine where the bot is running.
In case that disk fails, the files are lost. So it would be nice to back it up to more resilient storage.

Add logging and tracing to event handling. Honeycomb for tracing and Sentry for exception logging seem like solid candidates and both have free tiers.

• Add tracing with Honeycomb
• Add error logging with Sentry

Implement something like Levenshtein distance seems like a better fit than the custom implementation that is in place now.

getSoundNamesWithTagForServer from soundsHelpers.ts should not throw an error just because it doesn't find anything. Just return empty array and handle from client.