Backend Swagger - User interaction endpoints
Backend Swagger - Register account
Backend Swagger - Player endpoints - update profile and filters
Backend Swagger - Login endpoints
Front end: signed in, update player profile
Front end: login, form validation
Front end: Sign up form validation
Front End: Sign up as a new user
Front end: login/homepage
Front end: signed in, dota game filter
Front end: signed in, valorant game filter
Front end: signed in, show all, no filters
Front end: Card Modal
To Demo a Mock Profile
To demo a complete profile, use these as your credentials on login.
The inspiration for Rallee (/ˈræli/ , 'Rally') comes from a desire to be able to connect and find teammates for your games in one consolidated place. Our team has seen 'Looking for Group' on Xbox Live, Steam, Battlenet, etc. We've seen CS:GO's interpretation for just their own game. But what we want to do is consolidate - no more signing into yet another account to look for a group for the other game you want to play. No signing into another website for only competitive teams. This is perhaps the most important feature of this team - half of our team are Leads for competitive League of Legends and DotA2 tournaments.
What it does
Rallee connects players who are looking for the same things in their gameplay experience. Rallee provides a way for users to filter other players based on their skill level, language, time zone, and whether the players are looking for competitive games. Rallee gives its users the ability to get a high level overview of many players at once to make it easier to find exactly what the user is looking for in a teammate.
How we built it
For the front end, we initialized a ReactJS application and incorporated Bootstrap to further streamline the styling process. We at Rallee spent a considerable amount of time looking for the right fonts, backgrounds, and accent imagery that would provide the right feel for our gamers and keep our pages relatively lightweight. We made a point not to integrate any heavy frameworks or dependencies without a good reason.
For the backend, we initialized a Java-Springboot application and created Docker containers that would initialize an AWS DynamoDB, its relevant tables and keys, and build and launch the Springboot application. We operated on a similar mindset on the backend of not bringing in any additional dependencies without a good reason. For this reason, we set up Swagger on Tomcat and tested our APIs through Swagger and Postman.
To coalesce between the front end and back end, our team worked closely together to define our data models and anticipated payloads, as well as put emphasis on being able to work collaboratively. For this reason the front end is hosted on Netlify and the backend has a simple to use docker-compose script, allowing the user to launch easily the full stack environment on their local machines.
Challenges we ran into
The backend ended up being very challenging and ultimately isn't utilized by the front end by time of submission. Our first task was to register a user, which seemed to go well. Our database contains the email, an encrypted password, and an id upon hitting our
/signup endpoint. Logging in was not as easy, and where we unfortunately got stuck for the entire weekend. We attempted to create a simple JWT implementation that authenticated with the backend, but we were continuously hitting 401s and 403s - even after taking a much more lenient whitelisting approaching to the APIs to attempt to bypass the currently nonfunctional
The backend team ended up being spinning our wheels on the endpoint, and did not complete other the other myriad of endpoints that the front end team needed - so the front end team had to create an entire fetching service to populate mock data and then hydrate mock data into the service. For the front end, filters were challenging. This was also because of sending the payloads to mock data.
We had also hoped to integrate an Instant Messaging functionality, but due to the timesink that became the auth endpoints, session data, and mock data, we had to scrap the feature and left stubs to show the future intent.
Accomplishments that we're proud of
The site looks great. It really looks like a page made for gamers, by gamers. It has a cohesive color scheme that is easy on the eyes without being yet another gray/dark theme. It includes many small details, including the illusion of depth on player cards, high resolution imagery on the cards that match with what game the player's card is for.
Related to the color scheme, we're also very pleased that we were able to find such an aesthetic pallet that was both very Team Liquid and very "Gamer Vibes". For example, we picked our title font because of the comment "Hey, it looks like my motherboard!".
We're also proud of our filtering work. Being able to choose what kinds of players you're looking for adds an incredible amount of versatilty to how our application can be harnessed by gamers.
What we learned
Marguerite learned React and made a super beautiful front end in two days! More detailed, Marguerite learned how to use routes, form validation, JSX formatted DOM elements, element state modification, and injecting mock data and building data models in front end applications. She also further cemented her understanding of ES6 syntax, Bootstrap functionality, and more powerful tools in SASS and CSS3. This is her first hackathon and only a sophommore in her undergrad.
Riley is a great teacher and mentor for our newbie, who brought confidence and skill to our front end and helped bring Marguerite's vision to life.
Emily learned DynamoDB. Her previous experience was heavily in CosmosDB, MongoDB, Postgres, and MySQL. Handling the schemaless and key-dependent database in her most comfortable heavyweight framework (Spring) proved to be a rewarding learning experience. This was another chance for Emily to act as a project manager and coordinator, which every new project offers new "hindsight 20/20" learning opportunities.
Alex worked with Spring for the first time in a long time, and faced the reality of @Beans. Unfortunately for Alex, @Beans don't make guice. Alex also worked tirelessly to create a deployable container to ensure consistency among development environments and deployments, learning a lot about how containers work with locally executing software.
What's next for Rallee
We will probably wipe out our backend and restart that. Maybe we will use a different framework and/or database. We may just refocus our efforts on the other APIs and remove the authentication for now, since our front end has a successful mock of login and signup. Most limitations including the lack of persistent storage can be resolved by putting more time into the backend.
We want to add the chat functionality we originally envisioned.
We want to add adding a user/connecting with them. (Like social media!)
We want to add additional games.
We want our users to be able to connect to their other online platforms they already use - Steam, Battlenet, Riot, etc.
We want to further expand the rank and role features as well. It's important to us that this information stays game specific. We may want to add min/max values for rank in the filter in the future, if people think it would be more useful than just a rank tier.