I had always seen requests for it on various Swift posts. Someone will post a long lyric acronym, and someone else who isn't in the know will be frustrated and lament a site like this not existing.
It's pretty basic right now, but you can search any acronym thats between 4 and 50 letters long, and it will tell you the song and album of any match.
Behind the scenes, there are 30,000 files, split by the first 4 letters of the acronym, so when you do a search you'll pull the file that matches the first 4. Eventually I'd like to make it so you can get more letters from a short acronym, but I had to start somewhere.
I have no skin in the game for the app itself, I just saw your post on the “front page” while scrolling and shitting….
there are 30,000 files
I’m more intrigued why you appear to be managing this with files. Why not use a database?
Edit: you’re also not handling misses very well. I just tried a random string and got the below error. That doesn’t tell me if it was my fault or a server error.
An error occurred while processing your request. Please try again later.
I appreciate the reasonse, even from a non-swiftie.
Yeah, that error message is left over from an earlier version where I sharded by acronym length instead. At that time, there would always be a file. The problem was the files were getting to be huge at the 50 character length (20MB) and performance went to shit on poor mobile connections. So I refactored to shard by first 4, and files dropped down to a few K each and became a lot snappier.
As for why files, there are a few reasons:
This way, the data are statically hosted, which means I can take advantage of a number of different free hosting services. In this case, I used firebase.
The data doesn't change frequently. There's gonna be two more re-records released, and then we'll probably get back to the old cadence of an album every year or two.
Why would I use a whole ass database if I could avoid it? From the client perspective, the request looks basically the same: "hey server, give me this data", but this way it's 100% static with a CDN, so the response will be sub-10ms for a lot of people
Not doing any processing server side means I don't have to worry about it going viral and breaking under the load.
Yeah, that error message is left over from an earlier version where I sharded by acronym length instead. At that time, there would always be a file. The problem was the files were getting to be huge at the 50 character length (20MB) and performance went to shit on poor mobile connections. So I refactored to shard by first 4, and files dropped down to a few K each and became a lot snappier.
I don't think that's necessarily true. I just tried a random string, and I got the correct 404 response back, but it doesn't look like the app handles that case and it just prints that error on any error.
.catch(error => {
console.error("Error fetching or processing the JSON file:", error);
displayError("An error occurred while processing your request. Please try again later.", tableBody);
});
Anyway, I wasn't trying to shit on it. Good job :)