Service availability: external Ids
Closed this issue · 5 comments
Right now, lighterpack uses a newline-delimited file for its "external Ids". These are the Ids that show up in the URL when sharing a list.
We're running out of the original list of external Ids. We could generate a new list (would need a script that checks for uniqueness against the existing database), or come up with a different solution to generating or storing these Ids.
Have you considered shifting towards GUID/UUIDs?
We'd no longer need to maintain a list of Ids and we wouldn't have to run uniqueness checks. This problem would be solved in perpetuity. The downside is that the share URL wouldn't be quite as pretty...
As lighterpack continues to grow, I'd imagine this is an eventuality to alleviate constant maintenance of the id list.
I love UUIDs! But I'm not sure they're the right choice for this application.
When we look at other popular services like imgur or gfycat we can see they use less intimidating-looking URLs (short alphanumeric strings for imgur and a series of random words for gfycat). I think there's merit to sticking with something like these.
But yes, the goal is to remove the constant maintenance. Maybe we could have a cron job, or some code that generates new IDs after an ID is returned from the server (to avoid blocking any user on ID generation).
And perhaps using a DB table would be better than a flat file as well (or maybe that's better for after the postgres migration).
I totally understand not wanting to use UUIDs.
Imgur probably uses a hash function to generate those ids on the fly. I think we could, too.
Here's an idea: We generate a UUID and use a hash function to squish it down to 7 alphanumeric digits. With 36^7 possibilities we shouldn't have collisions very often, if ever. Just in case, we should check the generated value against the database. If it already exists, we start the generation process over.
The sticking point here would be the query to check if an id is already taken. If the query is fast enough, the small delay to the user shouldn't be too annoying.
Adding more moving parts like a cron job or new db table to support Id generation sounds worse than using a flat file, in my opinion.
I found an npm package called shortid that was designed to solve the issue we're facing. Lemme know what you think!