6 comments

[ 4.4 ms ] story [ 17.9 ms ] thread
Thanks for sharing. A few suggestions to add: secure, signup, login

I've had the secure problem in a previous app. Had to change the subdomain of the user, luckily he was inactive.

You know, I had a similar list for an API-based side business during development. The closer I got to launch, the more I would add, until I finally dropped support for subdomains and simply went with nested URLs. Is it less pretty? Sure. But I've already made plans to use multiple sub domains for sub-products that I wouldn't have put on that list.
Definitely.

I was considering adding 2-letter language codes, and that list only is > 100 items.

I already thought about breaking up the list into multiple categories, I can really see how it can get complicated (and ugly) pretty quickly.

A subdomain makes the app look a lot more trustworthy IMHO.

Nice, but missing who knows how many. `developer` is on the list, but not `dev`. Not sure how to avoid that kind of confusion systematically, but I appreciate the attempt.

Honestly, this is essentially why I have no interest in letting third parties dictate anything that shows up in DNS records. /slug/rest-of-url works great for me -- I'd almost recommend a lot of developers see this _so that is dissuades them from using dynamic subdomains_ more than recommending it as a technical countermeasure.

Yes, I've added a lot of them in the meantime (and added a validator written in PHP).

I think it will be hard finding a list that makes sense for everybody. It's a tricky problem.

Use the opposite: a yourservice.customerdomain.tld cname.