Name: Aadi Bajpai
Email: [email protected]
University: Vanderbilt University, Nashville, TN
GitHub: @aadibajpai
Website: aadibajpai.com
Potential Mentor(s): Carlos Fernandez Sanz, ...
The Beacon project is essentially an application to allow a set of followers to track a leader on a map. This has use cases for all sorts of guided tours and hikes and biking trips, where there is one person leading and everyone else following.
From a technical standpoint, the backend would implement the core functionality of leader-follower pattern (which is somewhat like multiple values on a single key) where every follower is able to see the leaders location with a two way binding so that the leader can potentially see all the followers. Along with this, some convenience features like sharing beacons or saving locations/routes that have been visited would also be addressed by the backend.
One of the important design considerations here is scalability since it is important to make a system that handles load. Additionally, since frontend and backend will be worked upon separately, it is important to agree on a common schema so that both parties can work on it independently. Since the location updates will be continuous, I like the idea of using websockets for it to provide a real-time two way binding between the backend and leader / followers.
With all of this in mind, I think javascript is the language to use although I could be convinced to go for typescript as well. For the scalability parts, Cloudflare Workers are fantastic and I’ve been using them a lot recently so using them to spin up beacon instances for the real-time interfacing is a good pipeline. This works since beacons have a duration attached to it, so the spinned up instances would not be running for more than that, and workers stop running as soon as they return their response.
Additionally, Workers appear to have support for graphql servers so that’s nice: https://blog.cloudflare.com/building-a-graphql-server-on-the-edge-with-cloudflare-workers/
Another option instead of, or along with, Workers is GCP Cloud Functions with Firebase for databasing since Workers are less mature for databases. If we just use Workers for lighter work and starting up instances, then I’m pretty sure we can fit under the free tier. The demarcation between what the instance handles and what the serverless part handles is important here.
Firebase Realtime Database (https://firebase.google.com/docs/database) talks about data being synced across all clients in realtime, which sounds like a perfect fit for the location sharing part of the Beacon project. The edge function could potentially spin up a db to be used by the leader and followers and later shut it down once the beacon ends. The Realtime Database has a generous free tier, with a pay as you go paid plan (https://firebase.google.com/pricing). I observed a lot of the Beacon take home assessments involved Firebase in some capacity so this might be a good step, although it does lock the project in to it. There is also the option to use Firestore if that meshes well with our scalability needs: https://firebase.google.com/docs/firestore/rtdb-vs-firestore
Apollo GraphQL is a good way to decouple frontend and backend development. In the initial steps of development, it would be good to finalize the schema with the frontend team and then work on it.
For the server itself, Express works since it’s light and similar to Flask.
The flow of the program looks fairly straightforward to me, the app has options to start a beacon as a leader for a time duration or to join one, given a shortcode. Once a beacon is started, the link can be shared for direct joining. This demonstrates essential API calls for starting a beacon, registering a user as leader, assigning a shortcode, and then allowing other people to add themselves to it. A stretch goal here is to allow the leader to see other followers and take actions based on it, for example making sure no one is lagging, or even making some other user the leader.
During the duration of the beacon, the leaders location is shown and it is possible to mark locations or save routes for sharing later. I think it is important to make this part extensible, to allow for more features in the future for when a beacon is active (e.g. the leader marking out stuff for all the followers to see, or some sort of short communication interface like if a road is blocked further ahead then the leader can send a heads up to the followers far behind).
The way I see it, the leader starting the beacon API request would trigger spinning an instance up. An easy way to scope followers would be to let the clients directly interface with this instance, so they’re automatically scoped to it.
For the location sharing, if we use websockets then that will easily allow returning the location information agnostic of the format, so frontend can choose whatever is convenient for them to display.
For the shortcode, I think we can go for something short and memorable. Even a small 4ish letter link would work since all beacons are short duration and even with 4 letter alphabetic, there are 26^4 = 456976 beacons that could be active all at once with a link to share like bea.con/WXYZ which has the advantage of looking cool.
Adding people does not seem hard, since it’s a general observer to be set up to receive information from the leader.
Transitioning leaders should not be bad either, since it’s simply changing roles.
Saving routes or landmarks can be made a property of the user, so they can save that information in any manner the frontend team decides is the most convenient.
In general the workload this year is half, but I think this project is in a lot of ways what you make of it—it could be a full summer project too. Also, one of the major things here is to get the initial scaffolding out of the way first, since then it should be relatively painless to get it working.
Additionally, as with all new projects, it is a good idea to be pessimistic in planning since stuff ends up taking more time than we think it will.
I like this project because it’s something that is tangibly useful, completely new and offers me an opportunity to work with a lot of new technologies. It would be really interesting to see this out in the real world hopefully. Last GSoC was great in that I worked a lot to extend existing tech in various ways but this is simply a fresh new project to start working on. I had a great time last summer with Willem and I think it’s fitting to ring in my last GSoC with CCExtractor—a place I’ve been with since 2017 Google Code-in.
Overall, I’m very pumped to work on the Beacon Backend with CCExtractor this summer and I think it will be a lot of fun! Thanks for having the project and offering me the opportunity to work on it.
I am Aadi, a rising sophomore at Vanderbilt to study computer science with a math double major possibly some other things. At Vanderbilt, I lead the dev team (~12 developers) on VandyHacks.
I have been deeply involved with open source software since 2017 when I chose to compete in Google Code-in with an organization called CCExtractor Development. Since then I've been a Google Code-in Grand Prize Winner, 2x mentor, Google Summer of Code mentor, and student last year!
Programming-wise, I generally worked with Python but have been working a lot with JavaScript recently, and I do C++ for all my classes. If needed, I have no doubt I can pick up whatever is required quite smoothly.
Other than programming, I've found an interest in speaking at conferences and travelling when I can. Academically, I'm interested in privacy and anonymity research which I am also doing this summer with a professor on an NSF grant.
Through Google Summer of Code, I hope to acquire professional skills and more work experience with modern technologies while implementing something that will be used by real people to solve a real problem.