Discussion: Rebuild Help Queue Architecture

[webecke]

Note

I wrote a lot of words. In summary, we're trying to figure out the best way to approach a new Help Queue system. I'd specifically love to hear from @frozenfrank @ThanGerlek @19mdavenport, but everyone is encouraged to share their thoughts, whether or not they're a contributor yet.

Currently the help queue, while great, isn't flexible. We haven't quite figured out how to run it in a development environment, and its in PHP, meaning there's a whole new learning curve for CS 240 devs to make changes. Its been proposed that we rebuild the helpqueue with technologies familiar to CS 240 TAs and students.

Benefits we hope to get out of rewriting the Help Queue

• More adaptable help queue
• Tie ins with Autograder
• New features
  • Link repo/submissions
  • Indicate to student who is helping them
  • Help Queue limit mechanisms
• Easier onboarding for new TAs (familiar tech stack)
• Better local development experience
• Opportunity to add automated tests
• Modern frontend framework capabilities

This raises some questions, most notably, how it should be set up. There's a couple proposals, and this issue is to provide a place for us to discuss how we think is best to do this. I'm already working on this, but a lot of it will depend on what we decide here.

Proposal 1: Help Queue as new Autograder feature

In this proposal, the help queue would just be another part of the Autograder. It would be built into the autograder front end and backend. We would put all code in one repo and run it one domain, one AWS instance, and one server process.

Pros

• Unified database and API
• Easy to pull student data from the Autograder
• Simple deployment
• Shared code

Cons

• Seemingly separate systems (grading/helping) are tightly coupled
• Help queue doesn't easily transfer in the future when Autograder gets replaced
• HelpQueue and Autograder are codependent
• Poor separation of concerns

Proposal 2: Help Queue as Autograder sibling

In this proposal, the help queue would be still on the same repo, and the backend could be on the same AWS instance (I'm not exactly sure how, maybe a different port for the help queue) but the HelpQueue and Autograder backends would run as different server objects, and the front ends would be located in the same folder, but loaded as separate components.

Pros

• Unified database and API
• Easy to pull student data from the Autograder
• Shared Code
• Not as tightly coupled as Proposal 1

Cons

• Not a simple transfer when Autograder gets phased out eventually
• Might need a reverse proxy
• Potentially more complex deployment
• Poor separation of concerns

Proposal 3: Help Queue as Independent service with Autograder "plugin"

In this proposal, the help queue would run on a separate subdomain, and in every regard be a separate application (including a separate repo) but we could build a "plugin" to make requests to the Autograder to get info from there.

Pros

• Much cleaner separation of concerns
• Help Queue survives easily when Autograder gets phased out

Cons

• How is auth managed? Do they both do auth separately? or does one rely on the other?
  • Maybe they share JWT tokens? So signing in on CAS with one unlocks the other?
• Potential for duplicate code
• More work to get data from Autograder

Proposal X: Idk everything. Comment better ideas if you have them

I don't know everything. Throw your ideas below, or discuss the ones I listed already.

[19mdavenport]

Honestly I think Proposal 1 would be the easiest to implement and maintain. The systems wouldn't have to be that tightly coupled, and if/when the project ever gets replaced, hopefully they won't have to replace the auto-grader, just adapt it. However, I am interesting in seeing what other people think.

[webecke]

I think after lots of in-person discussions with several TAs, the consensus is to just leave the help queue as is. Its not a great system, but its probably not worth the time to replace at the moment.