A name like no other...

So, I started writing another tool today (aName) because I found myself yet again trying to solve this problem. This problem being usernames and all the idiosyncrasies that go along with developing with and around them. I most often use Keycloak in my projects for authentication along with OAuth integrations the likes of Google, Github, etc. When one authenticates using Google for example, Keycloak will set the username as the user's email address by default. I didn't particularly like this (maybe it has something to do with the trauma and scaring I have received from the Node.js community in the past regarding precious email addresses... lol) and it finally reached the point on the particular project I'm working on currently, where I started to "fix" the problem. A few thoughts came to mind, using the Keycloak API to update the username... which still left me with the task of generating one, just using the sub field on the Keycloak user object... which I have always felt slightly uncomfortable with for some reason that I would rather not delve into right now (but I will say that I have generated opaque ids based on the sub and using UUIDv5... and that was a bit of management in and of itself, mapping the sub to the osub and/or generating and comparing?!). Furthermore, I've had cases where usernames were generated and then a database lookup needed to be done to confirm that the username didn't exist already as to avoid any nasty collisions (yeah, because the userbase on my projects is so massively scaled! ...) Anyway, instead of writing and rewriting the same bits of code over and over, because at this point I think I've done those bits enough, I started in on this tool where the goal is for it to be a robust endpoint that can be used from anywhere (web) to simply give a deterministic username with a fair amount of anti-collision probability and just leave it up to the user and/or some other lazy mechanism to correct any collision that probably never happens. After all, as long as my systems are designed to rely on the true user id (the sub) and keep usernames as simply a vanity abstraction... this should work right? Less hits to the DB to incessantly check to see whether the stars aligned enough for some poor soul out there to be chained with the username: "kind-pink-meal"... or worse yet to have picked it (actually, I like the name), less code to write, less drudgery, more fun.

Current Options

So of course, I searched for other options this morning before embarking on this side... "side quest" that's it, that is what the youngsters call it right? Anyway, after embarking on this side quest, I definitely did a bit of diligence to check for any simple plug and play solution, because I love plugging and playing on front quests. Alas, I didn't find anything after an old school Google search (see what I did there) nor via the almighty ChatGPT (it sucks). In fact, the latter, as it so often does, and so very transparently I might add, spoke platitudes about how great "my idea" was to create this "new" tool and that such a thing was such a missing gap in the ecosystem... bla, bla, bla, bla, bla.

I will say that NPM turned up several results as far as naming and id generation but a big peice of the requirement was DETERMINISTIC and while nanoid, and uuid are gotos, they did not fit the bill in this case. The runner up was https://github.com/andreasonny83/unique-names-generator but that was still just an NPM package and not really a service. I would still have to implement the code, I mean more than just here's some string, please give me a DETERMINISTIC username that will always be the same given the same string... DONE.

Taking it all with a grain of salt, I started in.

Two Weeks Later (almost)...

So, a bit more fiddling and dog fooding and we're at a more complete solution! Here's a list of things added since, because I know you care:

• A bunch of bug fixes but that's to be expected when software is just birthed.
• Proper drag & drop for the dictionaries, and more dictionaries.
• HA proxy routing lookup requests to the appropriate GitHub repos (CDN)
• Fleshed out the splash page which is essentially just a sugar UI to explain things but not really a primary use touchpoint (I don't think)
  • Deterministic Name Generator definition/explaination
  • Example code to show real world use
  • Fanciful Shakespearean copy
  • Plan chooser connected to Stripe and integrated with auth server roles
  • Lookup UI to demonstrate retrieving generated names, both from the backend and from GitHub
• Integrated into the original project that I was working on which led to this tangent!
• ...