···11BOT_TOKEN=#Get this from https://discord.com/developers - REQUIRED
22BOT_CLIENT_ID=#Get this from https://discord.com/developers - REQUIRED
33-DB_URI=#Your MongoDB connection URI - REQUIRED33+BOT_ADMINS=#Discord Ids of bot administrators, comma separated
44+DB_URI=#Your MongoDB connection URI - REQUIRED
···11+# Voidy Architecture Overview
22+The Voidy architecture is a complete re-imagination of my previous bot's command and event organization architecture.
33+44+Instead of relying on loose commands and events in respective top-level directories, the new approach groups all sorts of handlers into a single "module".
55+66+And to allow even better handling of data, modules are managed by an even higher entity, "registries".
77+88+Registries have a standalone database, used to store data of included modules.
99+1010+A more detailed explainer of each system can be found in the related markdown files.
+35
docs/architecture/top-level.md
···11+# Top level architectural overview
22+Anything happening before, or required by, our registries, is considered top-level architecture.
33+44+This includes utilities such as the command and event handlers, which are consumed by lower levels of the system.
55+66+We'll go through each of the top-level components below.
77+88+## Loaders
99+Loaders are static classes, which provide utility methods for recursive loading of data from a data source, usually a directory.
1010+1111+The constructor of a loader always takes one parameter, a string/path pointer to the desired data-source.
1212+1313+Each loader additionally implements an asynchronous `collect` method for initial data collection.
1414+1515+Finally, loaders provide various means of exporting data in supported formats, through methods like `getJSON`, `getCSV` and more...
1616+1717+### Event loader
1818+The event loader walks a directory and stores data from any file exporting an object that follows the Event type structure.
1919+2020+### Command loader
2121+The command loader walks a directory and stores data from any file exporting an object that follows the Command type structure.
2222+2323+## Handlers
2424+Handlers are static classes, which receive exported data from Loaders, though not directly, as Loader data is usually fetched by a Registry, and the Registry invokes a Handler to get data into our queue system, more on that later.
2525+2626+Each handler has an `invoke` method, which takes JSON data, though it must always use the common exported JSON structure provided by Loaders.
2727+2828+Any data filtering or mapping is then run in the background by the invoked Handler, which ultimately pushes data to the queue, and triggers a "handler::postInvoke" event afterward.
2929+3030+@Todo: document Handler lifecycle events
3131+3232+## Lifecycle manager
3333+The Lifecycle manager is a simple event manager with a fancy name, it stores subscribers of events in a map, with the event name as the key.
3434+3535+Additionally, it implements two very simple methods, notify - which fires lifecycle events, and subscribe - which subscribes a callback function to an event.