Building a Better SimpleEnroll
At Stanford, we have a system called "SimpleEnroll" that allows us to enroll in classes. It's famously awful software – on enrollment day, around 2k students all click a button at the same time, and the system usually crashes. It's also just old – the entire system feels like it was built in a day, and was never thought out. Basically, it's traditional enterprise software at most colleges.
At Stanford, my dorm has an event called "Saturday Suppers" where one of our RAs (Jake!) takes people to a local restaurant in Palo Alto. (The first week was In-N-Out, the 2nd was some asian BBQ place in Mountain View). Demand for these events is high – at Stanford, frosh aren't allowed to have a car so our off-campus mobility is limited. Also, it's fun to get food with your friends! The first Saturday Supper used WhatsApp to organize sign-ups. Jake took a screenshot of a message every time someone liked it, and then identified who had liked the message first. I thought it was an awful system, and offered to build a new one. Looking to improve on the interface of SimpleEnroll, I dove into the task, and enroll.stanf.org emerged a few hours later. Here's how I made it:
Because enroll.stanf.org aspires to handle massive amounts of registration at once, many of the architecture choices come from the need to prevent race conditions and other anomalies. When a user clicks the "join" button on a given event, their request is added to a requests table with their identifying information (user, event, and creationDate) along with a type column which is initially set to pending. Then, every second, pending requests are either moved into the event (type is set to enrolled), moved onto the waitlist (type = waitlist) or removed entirely if the waitlist is full. Users will always be added in the order their request was received.
In the browser, this "waiting for your request" period is shown as a modal, which just polls the database until the event is no longer pending. This model works fairly well, and isn't susceptible to the many issues with just adding the event directly (such as needing to do those modifications on the server). I'm sure there are problems with this approach, but it was fun to build, so I don't really care!
Plus, this past Saturday, the system worked perfectly. Once the event was created, Jake sent the link in the chat, and it filled up fairly quickly. He also asked me to make a few modifications (such as moving the enrolled users around) which only took a few minutes. Overall, the project probably took around 3-4 hours, and works well! I'm also happy with the design, especially the user of color (it even has dark mode!).
A few fun facts about the project: first, it uses Google Authentication with a query param to only allow users to select their Stanford account. Our Google login actually just redirects to our own OAuth, so the experience is usually seamless, and the user can't really tell that Google is being used. Second, waitlist management is actually done by modifying the createdAt date on a given enroll request. It's a bit of a hack, but actually works fairly well for moving users on and off the waitlist.
This project was definitely in the category of "a fun solution to solve with code." When starting these sorts of projects, I always end up asking the same three questions, and getting the same few answers: Are there already tons of projects that do this same thing? Probably. Are any of them as simple as this to use? Not that I could find. Are any of them made by me? No. As long as the last question is a no, and I'm excited about the project, you can bet I'll drop everything until it's ready to ship.