## Inspiration

On our way to PennApps, our team was hungrily waiting in line at Shake Shack while trying to think of the best hack idea to bring. Unfortunately, rather than being able to sit comfortably and pull out our laptops to research, we were forced to stand in a long line to reach the cashier, only to be handed a clunky buzzer that countless other greasy fingered customer had laid their hands on. We decided that there has to be a better way; a way to simply walk into a restaurant, be able to spend more time with friends, and to stand in line as little as possible. So we made it.

## What it does

Q'd (pronounced queued) digitizes the process of waiting in line by allowing restaurants and events to host a line through the mobile app and for users to line up digitally through their phones as well. Also, it functions to give users a sense of the different opportunities around them by searching for nearby queues. Once in a queue, the user "takes a ticket" which decrements until they are the first person in line. In the meantime, they are free to do whatever they want and not be limited to the 2-D pathway of a line for the next minutes (or even hours).

When the user is soon to be the first in line, they are sent a push notification and requested to appear at the entrance where the host of the queue can check them off, let them in, and remove them from the queue. In addition to removing the hassle of line waiting, hosts of queues can access their Q'd Analytics to learn how many people were in their queues at what times and learn key metrics about the visitors to their queues.

## How we built it

Q'd comes in three parts; the native mobile app, the web app client, and the Hasura server.

1. The mobile iOS application built with Apache Cordova in order to allow the native iOS app to be built in pure HTML and Javascript. This framework allows the application to work on both Android, iOS, and web applications as well as to be incredibly responsive.
2. The web application is built with good ol' HTML, CSS, and JavaScript. Using the Materialize CSS framework gives the application a professional feel as well as resources such as AmChart that provide the user a clear understanding of their queue metrics.
3. Our beast of a server was constructed with the Hasura application which allowed us to build our own data structure as well as to use the API calls for the data across all of our platforms. Therefore, every method dealing with queues or queue analytics deals with our Hasura server through API calls and database use.

## Challenges we ran into

A key challenge we discovered was the implementation of Cordova and its associated plugins. Having been primarily Android developers, the native environment of the iOS application challenged our skills and provided us a lot of learn before we were ready to properly implement it.

Next, although a less challenge, the Hasura application had a learning curve before we were able to really us it successfully. Particularly, we had issues with relationships between different objects within the database. Nevertheless, we persevered and were able to get it working really well which allowed for an easier time building the front end.

## Accomplishments that we're proud of

Overall, we're extremely proud of coming in with little knowledge about Cordova, iOS development, and only learning about Hasura at the hackathon, then being able to develop a fully responsive app using all of these technologies relatively well. While we considered making what we are comfortable with (particularly web apps), we wanted to push our limits to take the challenge to learn about mobile development and cloud databases.

Another accomplishment we're proud of is making it through our first hackathon longer than 24 hours :)

## What we learned

During our time developing Q'd, we were exposed to and became proficient in various technologies ranging from Cordova to Hasura. However, besides technology, we learned important lessons about taking the time to properly flesh out our ideas before jumping in headfirst. We devoted the first two hours of the hackathon to really understand what we wanted to accomplish with Q'd, so in the end, we can be truly satisfied with what we have been able to create.

## What's next for Q'd

In the future, we're looking towards enabling hosts of queues to include premium options for users to take advantage to skip lines of be part of more exclusive lines. Furthermore, we want to expand the data analytics that the hosts can take advantage of in order to improve their own revenue and to make a better experience for their visitors and customers.
## Inspiration

The impact of COVID-19 has had lasting effects on the way we interact and socialize with each other. Even when engulfed by bustling crowds and crowded classrooms, it can be hard to find our friends and the comfort of not being alone. Too many times have we grabbed lunch, coffee, or boba alone only to find out later that there was someone who was right next to us!

Inspired by our undevised use of Apple's FindMy feature, we wanted to create a cross-device platform that's actually designed for promoting interaction and social health!

## What it does

Bump! is a geolocation-based social networking platform that encourages and streamlines day-to-day interactions.

**The Map**

On the home map, you can see all your friends around you! By tapping on their icon, you can message them or even better, Bump! them.

If texting is like talking, you can think of a Bump! as a friendly wave. Just a friendly Bump! to let your friends know that you're there!

Your bestie cramming for a midterm at Mofitt? Bump! them for good luck!

Your roommate in the classroom above you? Bump! them to help them stay awake!

Your crush waiting in line for a boba? Make that two bobas! Bump! them.

**Built-in Chat**

Of course, Bump! comes with a built-in messaging chat feature!

**Add Your Friends**

Add your friends to allow them to see your location! Your unique settings and friends list are tied to the account that you register and log in with.

## How we built it

Using React Native and JavaScript, Bump! is built for both IOS and Android. For the Backend, we used MongoDB and Node.js. The project consisted of four major and distinct components.

**Geolocation Map**

For our geolocation map, we used the expo's geolocation library, which allowed us to cross-match the positional data of all the user's friends.

**User Authentication**

The user authentication proceeds was built using additional packages such as Passport.js, Jotai, and Bcrypt.js. Essentially, we wanted to store new users through registration and verify old users through login by searching them up in MongoDB, hashing and salting their password for registration using Bcrypt.js, and comparing their password hash to the existing hash in the database for login. We also used Passport.js to create Json Web Tokens, and Jotai to store user ID data globally in the front end.

**Routing and Web Sockets**

To keep track of user location data, friend lists, conversation logs, and notifications, we used MongoDB as our database and a node.js backend to save and access data from the database. While this worked for the majority of our use cases, using HTTP protocols for instant messaging proved to be too slow and clunky so we made the design choice to include WebSockets for client-client communication. Our architecture involved using the server as a WebSocket host that would receive all client communication but would filter messages so they would only be delivered to the intended recipient.

**Navigation and User Interface**:

For our UI, we wanted to focus on simplicity, cleanliness, and neutral aesthetics. After all, we felt that the Bump! the experience was really about the time spent with friends rather than on the app, so designed the UX such that Bump! is really easy to use.

## Challenges we ran into

To begin, package management and setup were fairly challenging. Since we've never done mobile development before, having to learn how to debug, structure, and develop our code was definitely tedious. In our project, we initially programmed our frontend and backend completely separately; integrating them both and working out the moving parts was really difficult and required everyone to teach each other how their part worked.

When building the instant messaging feature, we ran into several design hurdles; HTTP requests are only half-duplex, as they are designed with client initiation in mind. Thus, there is no elegant method for server-initiated client communication. Another challenge was that the server needed to act as the host for all WebSocket communication, resulting in the need to selectively filter and send received messages.

## Accomplishments that we're proud of

We're particularly proud of Bump! because we came in with limited or no mobile app development experience (in fact, this was the first hackathon for half the team). This project was definitely a huge learning experience for us; not only did we have to grind through tutorials, youtube videos, and a Stack Overflowing of tears, we also had to learn how to efficiently work together as a team. Moreover, we're also proud that we were not only able to build something that would make a positive impact in theory but a platform that we see ourselves actually using on a day-to-day basis. Lastly, despite setbacks and complications, we're super happy that we developed an end product that resembled our initial design.

## What we learned

In this project, we really had an opportunity to dive headfirst in mobile app development; specifically, learning all about React Native, JavaScript, and the unique challenges of implementing backend on mobile devices. We also learned how to delegate tasks more efficiently, and we also learned to give some big respect to front-end engineers!

## What's next for Bump!

**Deployment!**

We definitely plan on using the app with our extended friends, so the biggest next step for Bump! is polishing the rough edges and getting it on App Stores. To get Bump! production-ready, we're going to robustify the backend, as well as clean up the frontend for a smoother look.

**More Features!**

We also want to add some more functionality to Bump! Here are some of the ideas we had, let us know if there's any we missed!

* Adding friends with QR-code scanning
* Bump! leaderboards
* Status updates
* Siri! "Hey Siri, bump Emma!"
## Inspiration

When we saw that HackHarvard had Earth and Space as a track, that immediately grabbed our attention because it seemed like a unique category to build a project in. After doing some research on the current user accesible data in the topic, we realised theres a lot of data available out there but very specific to specific companies. The idea grew on us that it would be really convinient to just grab and pick the fields we need and not have to worry about the excess influx of unused data. Thus came the idea of creating NexusAPI. Nexus translates to a black hole, pulls everything towards itself in a way how our application combines the massive ocean of APIs into one.

## What it does

We've seamlessly integrated multiple space and Earth-related APIs into one unified platform. With NexusAPI, you can effortlessly access and organize data on solar flares, geomagnetic storms, and space missions, weather and many more. Explore accurate statistical data from renowned industry leaders like NASA, ISRO, SpaceX. Simply choose your categories, and we'll deliver clean and structured JSON data for your specific development needs. No authentication required so Get ready to explore the cosmos and enhance your applications with NexusAPI today!

## How we built it

The project mainly has 3 components to it:

1. Backend - The backend is built entirely with Golang. The reason we chose Golang is due to it's seamless support in creating REST APIs, fast and scalable codebase and support with our database. We found numerous space and earth based APIs created by major organizations in various countries and finalized on 3 for the purpose of this Hackathon; NASA - The leading name for Space and Exploration in the world currently, ISRO - The Indian Space Research Org, recently soaring high with thier state of the art low budget rovers and finally SpaceX - Led by the sharp and witty Elon Musk. We parse the data from all these services, store them in a legible, relevant format.
2. Database - That brings us to the 2nd part of the project, the database. We decided to go with Redis as the database because it is something we have never worked with before and thought it might be fun to learn something new. Redis has been the database of choice for many Enterprise companies and it definitely a good skill to keep in hand. We stored all our data in this NoSQL Database using key value hash sets. For the MVP we currently processed over 2000+ pairings of data.
3. Frontend - Finally we have the front end. For this we used the trusty NextJS framework which manages your routing, directory structure and page handling. We decided to just make a single page app would be enough to showcase the power this API holds. The page allows users to interact with a smooth, modern interface to carefully pick and choose which data they need and based on that it dynamically generates a special unique endpoint.

## Challenges we ran into

We ran into plenty of challenges in these 2 days. First one was just working with Redis in general. Never worked with it before so had to dig through the documentation really deep. There is also not a lot of documentation around golang and redis and so had to figure out new ways and sometimes even had to reinvent the wheel out of necessity.

Secondly, it was trying to deploy our backend to a host online was a hurdle in our project. We had to migrate our database from a local server to a publically hosted server using dump rdb files.

Finally the Domain transfer took us a bit to figure out with GoDaddy and Google Pages and Vercel at the same time. Though not that big of a problem, it was a good learning curve.

## Accomplishments that we're proud of

We are proud that we were able to complete a project and build something we can showcase. Also the feeling of coding constantly for a whole weekend is really nice.

## What we learned

We learned how to work in a team, collaborate on github and most importantly how to work with Redis!

## What's next for NexusAPI

We plan to open source the NexusAPI project on github and let others contribute improvements to it. It would also be fun to see what people can build with it and experiment. We built it around just Space and Earth but the idea of this as a service in itself is something that can be leveraged into useful packages (node, python, golang). We hope people can use this API to just make their lives a little bit easier.