PubHop

Create, share, and go on a pub crawl faster and easier than ever. Over 200k bars, breweries and pubs mapped where users can get together.

The app allows users to register, create and manage multiple bar crawls. When a user signs up they get the ability to create a bar crawl by selecting bars on a map and order them in the route they want to go. Once they created the crawl they had the option to share the crawl with friends who would be able to register and join the crawl or view it without registering. Once a crawl had started notifications would be sent out to all the participants telling them where the first stop was. Once the crawl organizer moved to the next stop they would update the current stop and a new notification would be sent out.

The backend for this app was a server built on Laravel. It utilized Laravel’s queueing system to send out email/text/in app notifications. It also used MySQL to store all the users and crawls. The server also handled user authentication for the app. When a crawl was active the server would serve up a dedicated crawl “tracker” page that would give the viewer info of where the group currently was.

The frontend was built on the Ionic Framework using Angular then compiled out to native apps (web wrappers) for each device type, iOS & Android.

This project is a prefect example of how challenges can make you grow in your knowledge. The biggest challenge with this project had to be the scheduling and notifications of the whole thing. With every change to a “crawl” all the notifications to all the users associated with that crawl had to be updated and or dispatched. This also had to account for a users timezone.

The first part of this was to set up a cron job that would check the database for any notification that needed to be dispatched. The system I build to do that didn’t care what type of notification it was its whole job was just to trigger a “notification” Laravel event when it found something in the database that needed pushed. This cron job would run every minute since the scheduled notifications only needed to be accurate to within a few minutes.

Once the scheduling was taken care of I built out the notification event handler. Since there were multiple notification types: text, email, push and in app notifications, I had to build out an event handler for each type. For the text and email I used SendGrid and for push notifications I used OneSignal. As for the in app notifications, the frontend was subscribed to a WebSocket. All the notifications were scheduled as Laravel jobs so the apps performance didnt suffer while it processed these notifications.

With both those systems built out I had one last thing to do, build out the update functionality. When an event organizer updated a crawl’s schedule that would trigger a “reschedule” Larvael event. This event would then go and purge all scheduled notifications for all the attendees of a given event. It would then schedule new notifications with the new crawl schedule. This was all done with Laravel jobs as well so that way nothing was bottle necking any API response times.

Coming off of that project I had a whole new respect for managing notifications in mass while taking timezones into account. The biggest lesson I got from this was that A) I could do anything I put my mind to and B) testing testing testing. Test with as many edge cases as you can. Test with as many non bias people as you can.

Unfortunately the app did not have a long shelf life due to different business decisions. The code however still lives on as an archived repo I go back to from time to time when I need to reference things. I still have some of the cool merch from this project as well!