I’m Building A Web App!

Deciding to Build Something

I’m 8 months into my pivot from game development (still technically software engineering) to application-focused software engineering. I’ve spent the past 8 months as a frontend focused software engineer working for a startup building what I believe could be a pretty revolutionary system. The thing about revolutionary systems though is that they take time to build and while I enjoy the challenge there is also a very distinct downside which is that it is difficult for me to estimate when my first product as an application-focused software engineer will go live. In the early stages of my game development career, I built a few small games from start to finish as a way to be sure that I knew what I was doing. I’ve gotten to the point now in my software engineering journey that I believe it’s time to do the same.

Looking for Something to?Build

I did a very simple Google search and found a Reddit thread that had a link to a GitHub-hosted repo with ideas of a bunch of different things to build?—? https://github.com/Divide-By-0/ideas-for-projects-people-would-use. It has this under the “Music” section:

Tinder for Songs. Plays the most commented 10 seconds of a song on SoundCloud and adds it to a playlist if you like it. Inspired by Soundsieve (https://github.com/wilzh40/SoundSieve) which is unfortunately dead, and fab.fm which has a different song discovery method.

Note: This already exists for Spotify, namely Tuneful for a webapp, Discz which has an iOS app, and Swipify on the Play Store!

DONE: By Aditya Saravana for Apple Music on iOS

DONE: By Kevin Grosso for Soundcloud as a Webapp

I liked the idea. Sure, quite a few people have done it already and Swipefy (released in June 2023) already has over 500k downloads on the Play Store but all that did not matter to me because I was just looking for an idea to build, not an idea to start a company.

Starting the?Process

I knew I was going to build the frontend with React.js because it’s the frontend technology that I use at work. The question was…everything else. Let me walk through my thought process quickly.

1. I want to build this thing. Spotify forbids using a name that starts with "Spot" for a product built with their API. I'll name it Spinder.
2. Spinder will need a backend server to house any logic I don’t want to expose on the frontend.
3. The Spinder backend will have to interact with the Spotify Web API.
4. Spinder will need a database to store minimal user data.
5. I don’t want the Spinder frontend to ever make direct requests to the Spotify Web API.
6. I want Spinder to be fast.
7. I will use AI (ChatGPT) A LOT because I’m doing many things here for the first time and it just really helps.

I’ll use Express.js to build the backend server because it’s easy to learn for a backend newbie and it would also help me take a deeper dive into the world of Node.js (which essentially powers JavaScript these days). I’ll use Firebase’s Firestore as my database because I’m already quite familiar with it and Firestore’s real-time architecture will surely help Spinder be fast. I’ll deploy on Heroku, using Nginx as my web server. Nginx will also act as a reverse proxy and forward requests to my Express.js backend server. To clarify, Nginx serves my frontend React.js app statically, and my backend Express.js app sits behind Nginx only to respond to API calls. My React.js frontend will be allowed to communicate directly with my Firestore database in some capacity to avoid roundtripping through my backend server during the core operation of the app that requires speed. For downloading/streaming media, my frontend is served directly by the original host of the media (again roundtripping here will slow things down). Here’s an illustration of the fundamental architecture:

Armed with this illustration I was ready to start building.

The Current State of?Spinder

I started developing Spinder on the 22nd of January. At the time of publishing this article, the core application loop is complete. That means a user can get music recommendations based on some user-specific settings and choose to discard the recommendations or add them to a playlist. Getting to this point was not as easy as I expected it to be. Most of the work I’ve done up till this point has been in writing the backend (with minimal frontend stuff to test the app), and I’ve faced two surprisingly challenging issues so far:

1. Authentication.
2. Error handling.

Authentication

I spent an embarrassingly long amount of time figuring out the authentication system and here’s why. Spinder does not do any authentication on its own. I don’t ask users for an email or password; a Spinder user MUST sign in with their Spotify account. The Spotify authentication process is its own thing that is not very difficult to figure out. However, recall that in my architecture I allow the client to communicate with my Firesore database both directly and indirectly (through an API call to my backend server), and this is where the problem comes in. Requiring the Spotify authentication process only guarantees that a Spotify unauthenticated user will not be able to communicate with the Spotify API, be it directly or through my backend server in this case. However, as far as my database is concerned the client still has no means of authentication, and I simply cannot allow an unauthenticated client to talk to my database. Firebase has its own authentication system complete with a frontend package that you can use to authenticate clients but that does not work for me because I want Spinder users to only be aware of a Spotify authentication. After hours of wandering, I defaulted to the mantra I love to live by but too often forget?—?“Read The Docs!”. I took a closer look at Firebase’s authentication documentation and found a custom authentication system. Google had something for me, metal. The custom authentication system allowed me to add client authentication for database communication as an extension of the Spotify authentication process.

Error Handling

I like Express.js. I mean, my opinion is not super informed because it is my first backend framework, but the largely unopinionated way it works lets me breathe easily. Express.js however has a pretty specific set of rules guiding how you can handle errors gracefully without crashing your backend app. The challenge with error handling was not avoiding crashes (I could have chosen to just catch every error), but the challenge was making sure that when something goes wrong I know where it happened and why it happened. I don’t want to just catch errors, I also want to throw them. Errors seem bad but they are actually good. Without errors, unexpected behavior WILL fly under the radar. To avoid hair-pulling as my code grows, I needed to make certain that an error propagates as high up as possible before being caught so that by the time it is caught I have a very descriptive error trail in my log. I made a set of rules that I follow strictly, and it goes like this:

1. All operations that communicate with external systems and are prone to failure (e.g. Firestore operations, Spotify Web API calls) are abstracted away so that they can be “tried” in a try-catch block.
2. If they fail, catch them in the function that calls them. Log the error (failure reason) and throw another error describing what process failed to complete due to the failure of the base operation.
3. Continue this catch, log, and rethrow process until the entry point is reached (usually a handler function for a route).
4. At the entry point, catch the error finally (don’t throw it again or you’ll likely crash your app) and then take the appropriate action for the error which in my case is always to forward the error to dedicated error handling middleware.

And that’s it! After hurdling these two challenges, I was able to complete the core application loop as I described above without too much hassle. I used Firestore watchers to make sure that the backend can react to changes made directly to the database by the front end and also to allow the front end to react to database changes without having to make an explicit request to my backend server. The Spinder backend is now in a state where it works and is ready to grow and take in new features.

Spinder is still heavily in development and I’m eager to start building out the visuals for the frontend. Spinning up my first backend has been a very informative process and I advise that every frontend engineer explores the semantics of building a full-stack application to get a better appreciation of the system as a whole.

If you reached this point, thanks for reading! I’m still making posts following my series on Data Structures and Algorithms that I started here, and I will be making more posts about progress on Spinder in the future. Please subscribe if you’re interested in what I write!