Catching up

[tgarg10]

I think it might be valuable to comment on the decisions that I made in my implementations (as I make them) and how I implemented things so that it's easier for others to fix / debug later on.

[tgarg10]

A hybrid Three-layered Architecture

I have structured the Autograder's codebase to be a three-layered architecture with a few domain-driven aspects to it. More specifically, I have used the handler, service, and repository layer from the three-layered architecture and borrowed the idea of entities and drivers from domain-driven development.

On the whole, API requests that come in are handled by files in the handler. Here, the functions parse the incoming request body into its subsequent type that is defined inside entities. This is done so that other parts of the architecture accept a single common type. Also, whenever possible, I tried following the principle of "accept interfaces, return structs" to make it easier for us to replace things any singular layer whenever possible. If you're going to work with the handler, I highly recommend learning what Echo is (a go web framework that simplifies things).

The handler sends the corresponding entity, which is always a struct, that it creates to the service layer. The service layer performs any business logic, i.e., any thing that is special and not intuitive in our API. For example, if I need to check if a student is a junior for a specific thing, I would do so in the service layer, since this classifies as a special need / business logic. Similarly, sending an email would also take place through this layer even though the actual code for the sender lives in drivers (more on that later).

The service layer can call any driver that lives inside drivers and the repository layer. Things that might be re-usable should live in the drivers layer. This includes the authentication code, mailer code (code to send emails), messaging code (code to send text messages), slack API code (code that sends messages through slack), etc.

The repository layer makes all the interactions with the database. No business logic should be performed on this layer. Ideally, only Postgres queries present as go strings should be here.

[tgarg10]

Using our own Authenticator

I long debated on whether we should use our own authenticator (reinventing the wheel) or use the Google Gmail one. I decided to implement our authenticator as I want this project to be as independent of external factors as far as possible. Using Gmail's authenticator added a layer of reliance on Google Cloud's authenticator service, which adds complexity in setting up and tearing down the project. I will be using a traditional email-password login set up.

New Sign ups

The only way a user can gain a login into the grader is by receiving an invitation. The instructor can invite a student by entering their email (does not have to be a .edu email). The student receives an invitation link containing an invitation token. We store the hashed invitation token in our invitations table. When the student accepts the invitation before it expires (a parameter that will be given in the config.yaml file), he/she is prompted with a sign up page that requires him/her to enter their name, password, etc. Passwords are stored in the users table and are always salted by a secret extension found in the config.yaml file and hashed using SHA256.

Logging in

Whenever the user logs in, their credentials will be translated into a JWT token that we return to them. JWT tokens will have an expiry and will help facilitate sessions. They will also aid in authorization.

Authorization

Every API endpoint will have to authorize users before any action can be performed. We will be implementing Role Based Access Control or RBAC. Additionally, we will only be supporting three roles: Admin, Instructor, and Student.

Admin

• defined in the config.yaml file
• can add and remove instructors and students
• can view all assignments
• has all the privileges of an instructor

Instructor

• can access and modify grades
• can remove students
• can create and edit assignments
• can only view his own assignments
• has all the privileges of an assistant

Possible feature in the future: Assistant

• can view grades
• can invite students
• can only view the assignments he is added to
• has all the privileges of a student

Student

• can access assignments that he has been added to
• can answer on added assignments
• can view grades for past assignments

[tgarg10]

For now, the Assistant will have the same privileges as a student. Limiting the Assistant's privileges to certain classes, while giving them Student privileges in other classes appears challenging and will be revisited in a future update.

[tgarg10]

Front-end with Reach

For the React project structure, I have slightly modified the "Intermediate Folder Structure" from this guide. It does a great job at describing the purpose of each folder.