AANTS Backend

[MinhxNguyen7]

Description

• Implement the backend for AntAlmanac Notification System (AANTS).
• AA will periodically poll AAPI for section changes.
  • Discussion of the details of the API communications
• The polling script must be robust and also update with new PRs as part of our CI pipeline.
  • I.e., it cannot be an EC2 instance with a cron job.
  • We probably want to add another lambda as part of our stack (equivalent to another backend) that is triggered by a CloudWatch event. See this.

Requirements

See discussion below.

Open Questions

• When, exactly, should we send a notification?
  • What if a section opens, then closes, then opens again?
• How will we send emails? SNS or another service?
• From which email are we sending? Would it be proper to use the [email protected] email address?

Setup

Database

• Install postgres and pgAdmin instructions
• Follow backend.

Tasks

• Define requirements.
• Set up the database locally.
• Implement the script which polls AAPI, checks the subscriptions, and triggers notification sending.
  • As a dummy, just print the emails to the terminal
• Design the cloud architecture.
• Implement email-sending.
• Implement and integrate cloud system into CDK.
• Implement endpoint with auth for users to subscribe to a notification.
  • This will have to wait for auth to be finished (F2F).

Related Issues

• Requires Migrate to RDS #970
• Requires Sign in with Google #229

Useful Information

• The stack where we will add the resources is in apps/cdk/src/stacks/backend.ts.

[MinhxNguyen7]

I just have two modifications to the requirements:

• The user should be able to sign up for open, wait-list, and/or full, not just all notifications.
• The user should also be able to sign up for a change of restrictions.

The other requirements should be updated accordingly. Also, can you move the requirements to a discussion? That would be a better place for it, seeing how much space it is in the issue and the fact that it's not only to do with the backend

[IsaacNguyen]

I just have two modifications to the requirements:

• The user should be able to sign up for open, wait-list, and/or full, not just all notifications.
• The user should also be able to sign up for a change of restrictions.

The other requirements should be updated accordingly. Also, can you move the requirements to a discussion? That would be a better place for it, seeing how much space it is in the issue and the fact that it's not only to do with the backend

Yeah sounds good! About the change of restrictions part, I saw no mention of AAPI signaling when class restrictions are dropped in the discussion we had with AAPI. Would we have to call a separate AAPI endpoint for this or are class restrictions going to be an added output from the one we will be calling? Adding onto this, the only restriction we will be worrying about is the major-only restriction, right? I know there are other types of restrictions for classes but this is the only one I know about that makes sense.

[IsaacNguyen]

Requirements

• There will be a button for each course allowing a user to sign up for a notification subscription on the Added tab. They have the option to opt in for notifications when the class has requirement code changes, opens, becomes waitlisted, and/or becomes full. They can select only one or multiple.
• There can be a little tab to view all classes that the user has notification subscriptions for the quarter.
• Notifications about a current quarter's classes will stop being sent following the end of the second week of instruction (the deadline for to add/drop classes).
• The user can have the option to remove their notification subscription from a certain class from the Added tab, preventing them from receving further email notifications.
• Check changes and notify for current and all subsequent terms
• There will only be ONE email format that is sent. Based on whatever they are subscribed to, they can receive emails for individual changes (just waitlist, open, full, or code changes) OR multiple (waitlist and code change, open and code change, etc.)
• 
• The subject line of each should contain the class name and say it has had enrollment changes.
• Assuming we use AWS SES, the emails will be sent via [email protected]. Otherwise, it could be sent from an AntAlmanac email (assuming we have one).
• The email itself should greet the person (assuming we have their name), say how recent this information was gathered (time and date), mention the course name, time slot, and course code, and give the user a link to WebReg and AntAlmanac.
• No email will be sent if the class goes from OPEN to OPEN or FULL/WAITLISTED to FULL/WAITLISTED

[MinhxNguyen7]

I saw no mention of AAPI signaling when class restrictions are dropped

You should communicate that to them so they can add that as part of the response

[IsaacNguyen]

I saw no mention of AAPI signaling when class restrictions are dropped

You should communicate that to them so they can add that as part of the response

Got it. Just made a comment in the discussion.

[IsaacNguyen]

I saw no mention of AAPI signaling when class restrictions are dropped

You should communicate that to them so they can add that as part of the response

According to Andrew, it doesn't look like they can implement that unfortunately.