GELIFT weekend is a hitchhiking competition where teams compete against each other to be the fastest at the location. Challenges can be completed to receive a time deduction. GELIFT tracker is the piece of software that is used to publish the current location of the teams in the GELIFT weekend in real time to both the participants and the rest of the world to see who is closest to the finish.
The app is built on three main goals in order of importance:
- Availability, accuracy, and precision of the locations. The location is used for safety as well, so this needs to be available, accurate, and precise at all times.
- Ease of use for the participants. The set-up should be as minimal as possible to make sure they use this app instead of the other common solutions, such as Life360 or WhatsApp.
- Mobile first frontend. The frontend of the application should be easily accessible on mobile and poor WiFi, as it should be possible to reach while on the road (for the participants), and the link is generally shared on messaging apps on mobile.
The app works on three main components, as visualized below.
![]()
- Location publisher: For the location publisher, the OwnTracks app is used;
This app can function in two modes, namely MQTT and HTTP mode. For the first requirement, MQTT has been chosen, as it
off-loads some of this availability to existing applications. What is known for OwnTracks as "user" has been defined
as the teams, and what OwnTracks calls "devices" have been called "participants". So, for each participant "Pluk" from
the team "Petteflet", they publish to
/owntracks/petteflet/plukwith the messages described in the OwnTracks documentation. - MQTT Broker: As suggested by OwnTracks, the Mosquitto broker is used. Its responsibility is making sure that the location from the publisher arrives at the server, and is published to the Go backend. MQTT has some techniques for this as described in the protocol specification.
- Location API: The Location API is a piece of custom code that makes sure that the locations as received from the MQTT Broker are stored in an format that can be used by the frontend. This includes things like the team, the participant, the battery percentage, the time, but most importantly, the location. The location API does not calculate any extra properties, but does make sure that every entry is unique in terms of the MQTT message. Finally, it also exposes a single HTTP endpoint for serving the tracks that are stored in the database. The endpoint is public, and it is possible to create multiple frontends for displaying the tracks. GORM, Echo and Paho are used as libraries for the ORM, webserver, and MQTT client, respectively.
- Backoffice: The backoffice uses a very simple single password authentication, and allows very straightforward editing of settings. Or for easy importing of OTRC (owntrack configuration) files for participants.
- Location visualizer: The location visualizer is the React app that displays the tracks. It takes the tracks from the location API, groups this data by the user/team, sorts the data on timestamp, and calculates properties like distance to the destination. It also contains some settings for customizing visualization. For the maps Leaflet + OpenStreetMaps is used, primereact + tailwindcss for components and styling.
- Split the app into microservices, with a separate service for the MQTT server/client, the API, backoffice, and the frontend. This allows for more stability, the frontend can then be redeployed during the weekend without downtime for the Location API.
- Timeline to scroll back in time
- Add photos at locations for challenges and other things
- Backoffice for managing teams/participants
- Generation of OTRC files, and MQTT credentials for teams/participants
- Dockerization of the components
- Kubernetes deployment
- Restructuring of the backend codebase
- Admin backoffice for basic settings (start/end time, destination)
- Participant backoffice for easy OTRC loading
- Tried switching to maptiler, but ran into quota limits
- Initial release
- Visualize current location and history
- Switch between individual view and team view
- Switch permanent tooltips
- Switch on/off specific teams
- Info on who published and when
- Distance to destination and arrival time