This document should help describe the design of the system to help people get started on it.
We are using a relational database called PostgreSQL. In a relational database, data is stored in multiple "tables", each representing a collection of information about some thing. Tables can be connected to show relationships between them, such as members being able to work on projects. The current design is described in this image.
Note: As of right now, the tables for resources, expenses, and weekly announcements are not implemented in the database. They will be added once we have a better understanding of their usage.
We are using a Rust library called Diesel to use the database. It is made up of a command line interface (used to create the migrations folder and the schema.rs file) and a library with a set of Rust API to connect and modify the database without needing to write a lot of SQL. The getting started guide for Diesel does a good job off explaining how to use it in a simple case.
The migrations folder contains a set of upgrades and downgrades for the database. These define how the database is structured (in this case to reflect the database schema diagram). They are created with the Diesel CLI and SQL code.
The schema.rs file (located in the src directory) is generated by the Diesel CLI (so don't modify it directly). It is used by the Diesel library to connect the database structure to Rust code.
There are a set of models (for example, the member.rs and attendance.rs files) that describe the values of one item in each of the database table (so a single member inside of the members table). They also contain a set of CRUD functions to modify data from their corresponding tables.
To allow clients (like the website or Discord bot) to communicate with the back-end, we use what's called an HTTP Request in a REST pattern. This is a very standard way for websites and apps to send and receive data to and from servers.
These allow current clients (like the website) and any future ones to easily communicate with the server, regardless of platform. It also allows us to have authentication, so we can prevent some information from being publicly available (like a list of all the members and their emails).
We are using a Rust library called Rocket to handle the HTTP requests. This allows us to focus on the actual business rules, rather than worry about networking. They have excellent documentation on how to use it available here.
The standard Rust way of testing is to include them at the bottom of the code their testing. This makes it easy to keep them in-sync with the code they check. We encourage reading this testing document and adding as many positive and negative tests as you can think of in their respective files.
- The database-schema.png and database-schema.xml are used to visually represent the database's structure. The image was created from the XML document using a site called draw.io
- The extra-docker-info.md describes some extra Docker commands that might help solve some problems you could encounter as well as some very useful Rust tools for automatically styling the files and testing them
- The optimized-docker-info.md and optimized.Dockerfile was an attempt to make a very fast and small Docker image. It currently exists as an example for how to do that, though it isn't currently used nor does it contain the database needed to work with the project.