Inspiration
As we thought about what we wanted to create this weekend, we considered areas where an application could improve a WPI experience. Many WPI students either participate in work study, work for a department as a teaching assistant, or want to participate in research. Often, these academic employment opportunities are not widely advertised and are filled by word of mouth. While this system works, word of mouth rarely allows you to find the best talent possible for a role, so we thought of creating an application that helps students find academic roles to take up and helps professors find qualified and interested students to work with. This project was personal to our team, as the majority of us were interested in or actively engaging in research. It was particularly interesting to our team because some members of our group who enjoy math wanted to make a model for matching students to professors looking for research assistants.
What it does
Our application, reSearch_, starts by registering students and professors with the system by gathering some basic identifying information and data about the user's interests and expertise. Students are shown an interface where they can select filters for jobs such as degree program (undergrad, grad, postdoc, or doctoral student), desired student majors, project department, project location, hours per week, team size, and whether work study funding is required. Students can then apply to projects they find interesting. On a professor's account, they can see all of their listed projects and the students who have applied, as well as some random student recommendations. Professors can accept or reject student applications. When a student application is accepted, the application emails the student the professor's contact information to start a conversation about collaboration, although we did not implement the emailing part of the process. Professors can also reach out to recommended students to gauge whether they might be interested in joining their research team or academic employment opportunity.
How we built it
We chose to build our front-end in React and our back-end in an Apache web server written in Java. We used a MySQL database to store all of our data. Our React front-end uses Typescript as its primary language and Material UI (MUI) for React as a UI component library. Despite using MUI, we used a large amount of custom CSS and made some custom components for displaying information such as the login form and the list of jobs on the student end. The Java backend uses websockets to communicate with the front end. We used a websocket library created by TooTallNate on GitHub to implement the server. We created our own request handler which would parse out the request type. Our requests are in the form of JSON strings, which are easily parsable on the front end, but on the backend we chose to use the Gson library to aid in parsing JSON.
Challenges we ran into
One challenge we ran into was deploying our server so that it could interact with our front-end. The first challenge was finding a place that could host a Java backend, since this is not common for smaller scale projects. We ended up choosing to use a server which one team member had access to. We had initially wanted to host the front end using GitHub Pages; however, we ran into an issue with the websockets, one which would have required them to use WSS instead of WS to encrypt traffic. This was because the GitHub page used HTTPS. We pivoted to using the Apache server to host the website instead, since we would be able to run the connection over HTTP. Ideally, we would be using both HTTPS and WSS, but setting up certificates was something that we struggled to do. Another challenge was fitting all of the necessary data inputs into the UI and keeping their layout consistent across browsers. This is a styling problem that we tried to tackle but eventually had to settle on, since we didn’t have enough time to make a more responsive UI layout.
Accomplishments that we're proud of
One notable accomplishment from our team was our division of labor. We allocated one team member to UI, one to set up the server, another to create our database, and the last two to the algorithm we would use to match students to appropriate job opportunities. This subdivision helped us focus on our respective parts of the code without getting overwhelmed and helped us establish strong progress on each aspect of the project simultaneously. As different members of our team took breaks or addressed outside tasks, we reallocated jobs to ensure someone was working on immediately important tasks.
What we learned
Our team came in with a wide variety of experience. Several of our team members had never created a database or worked with them before. One learned how to set up a MySQL database and add the tables we needed. Several other teammates had little experience with querying a database, and they quickly learned how that worked. Another one of our teammates had never used websockets before; he learned how to set up the websockets in React and Java to facilitate communication between the front end and the back end.
What's next for reSearch_
There are several additional features which would improve reSearch_. The first is to secure the site with HTTPS and WSS. This would ensure that users are secure when logging in and not exposed to malicious actors. Another feature which would help the user would be the ability to send emails when a match is found. Since it is unlikely that every user will be checking the site everyday, having some other form of match notification would improve communication and ensure matches are updated faster. Additionally, we would like to allow professors to view students the app recommends for particular projects.
Log in or sign up for Devpost to join the conversation.