Database for per-server configuration

[themaxdavitt]

The bot needs a central database for storing persistent stuff - server configuration, user verifications, polls and other events that take place over time, etc. Something like MongoDB would probably work well as it scales well and doesn't require a lot of overhead or special setup for a JS implementation.

[eritbh]

For reference, MongoDB is a document-based database, rather than a relational one like SQL-based databases, though it has many analogous features. A MongoDB database is made up of collections of JSON-like documents, similar to tables and rows in an SQL database, except that the type of data stored in each collection doesn't need to be set up ahead of time; you can insert basically any document into any collection (though you can still set up document validation per-collection if needed). MongoDB also has features such as change streams, which let you have the database tell your code when something in the database changes. What is MongoDB? is a good resource from their website if you're new to it.

The way I'd do it, any bot feature that needs to store data in the database would use its own collections, rather than e.g. having one big "guild config" collection that stores all the configuration for each guild in one place. This will help prevent code in one area of the bot from accidentally messing with data in another area, except when it's specifically required.

For example, the database structure for the verification feature might look something like this:

• Collection verificationData - Stores all user verification data across all servers. Sample document:

  {
  userID: '122902150291390469',
  email: 'abc12@university.edu',
  }

• Collection verificationOrgs - Stores information about the various organizations that can be verified with (e.g. name, email domains, verification method). This table would only be modified by bot admins, e.g. to add support for a new organization to the bot or to update the email settings of an existing organization.

  {
  name: 'The University of Akron',
  emailDomains: [
    'zips.uakron.edu',
    'uakron.edu',
  ],
  }

• Collection verificationConfig - Stores verification settings for each server (e.g. what role to grant when verified, which organization(s) you need to be a part of, etc).

  {
  guildID: '591365313803583518',
  roleID: '192384468573154953',
  requireVerification: true,
  allowedOrgs: [
  ],
  }

[themaxdavitt]

I'm not very experienced with MongoDB, but the way you described seems like it would be a really good fit for this. I was looking over important schema design patterns as so long as we're ensuring we're following them (especially the schema versioning one), this will allow us a lot of flexibility in how we develop the bot.

Also, I wasn't really thinking about it at the time but it would make the most sense for us to combine all the architecture-related issues into one so we can easily look at how everything should fit together in one place. I'm closing this in favor of #9.