Volunteers are important. They fill in the gaps at different places and allow our community to grow and flourish. However, only 25.3% of people volunteer. There are many organizations advertising different opportunities, but little to none are centralized on one website.
We initially started to build an app to consolidate volunteering opportunities in the Urbana-Champaign area in one place. We were halfway through designing a robust website that would allow for users to see and respond to events happening locally when we realized that this site would be a “one-and-done” project. None of us were really inspired by the idea, and the rigor that was originally the driving factor of a project slowly decayed.
At this point, we reflected on the theme of the hackathon. What does it mean to be “open source?” How can we make something that people will actually use, as opposed to a one-off, unreliable web app that would likely be brushed off as technically insignificant? Although our project did strive for social good, we realized that no one would ever use it.
One of our teammates then introduced an idea that caused us to pivot.
What if we could create an API for other hackathoners to use?
As the field of CS progresses, we often are left wondering about the ethics that surround the field. Unremarkably, this results in most hackathons having at least one component of social good. Apps for people to volunteer to fix issues are common, almost customary.
During our research stage, we realized most volunteering API’s were quite hard to use, gave little information, had very poor documentation, or hadn’t been updated in years. As such, we decided to set up a tool for other avid, ethical “hackers” such as ourselves to use. Our vision is that this API will prove helpful during other hackathons where people decide to create volunteering or organizing apps. We enable the avid hacker to make simple GET/POST requests to our API to fetch all (already-posted) events and volunteering opportunities to use in their own social good proposals. To make it even easier, we created a React component and published to NPM so that anyone creating a project using React can easily implement parts of our API with just a couple more lines of code.
Design Process/Technical Details
npm i volunteer-connect-get-all
The actual API is served by a Firebase backend. We scraped over 50 events in the Urbana-Champaign area where organizers were looking for volunteers and stored them in a noSQL database. We have multiple GET and POST requests depending on whatever the user wants to do. These can all be found within our documentation on our GitHub repo.
Our test projects using this API were made using React (for the web variant) and React-Native (for the mobile variant). These both use POST and GET requests to retrieve data from our API and to post data to the database, which can then be accessed by API users in the future. Both of these projects are proof of concepts and thus do not utilize the full features of the API.
The project site (http://www.volunteerconnect.tk/) and the proof-of-concept React site (http://184.108.40.206:3000/) are run off a Google Cloud VM. The project site is served by a Linux-Apache-MySQL-PHP (LAMP) server and the React site runs off a Node.js server.
Challenges We Faced
The most difficult part was losing motivation a third of the way in. We were struggling with basic React Native while trying to build an app for our original idea. We pivoted to a website, where we faced the challenge of properly authenticating a user. This is definitely something we want to look into for future hackathons, as a robust user base could mean the difference between a failed hackathon and a startup. An additional challenge that resulted from changes in our project was keeping non-developers up to date with what was going on, as updating their art and presentations in an instant are not easy tasks.
We hope to keep the database updated so that other Illini hackers can use our project for their own hackathon ideas. With some more time, we could easily expand our database, adding even more events across the nation and functions. Additionally, we would like to add more GET and POST requests to our API, allowing developers more flexibility in how they choose to use it in their own projects.