If there was a way for me to send an email to myself in the past, I would send the following messages:
- Last Week’s Lottery Numbers
- A Reminder Not to See Spiderman 3
- Reasons to Not Use Subdomains in a Web Application
In Wufoo, we use subdomains to differentiate user accounts (http://username.wufoo.com/forms/) and honestly, it’s been nothing but trouble for us from a development standpoint. If we could do it all over again, we would have definitely handled our urls and account settings using a Flickr style setup using folders (http://wufoo.com/forms/username/). Here’s some reasons why:
Reason the First : When you want to offer your users SSL on these accounts, you have to buy a wildcard subdomain certificate that’ll cost way more than your normal SSL certificate. Prices range between $899 to $200 a year. We use Godaddy. Their interface leaves something to be desired, but they’re one of the cheapest and we love their customer support. One thing that we don’t like is that, since that certificate only works with subdomains, we have to do things like
https://secure.wufoo.com/login/to get an encrypted login url rather than having a simple url like this
https://wufoo.com/login/for our users to follow (and we’ll be damned before having to pay for two different certificates just for this kind of functionality). If we had just set up users to have their own directory as opposed to a subdomain, we’d have only needed to purchase a regular SSL certificate, which you can get for as little as $20 a year, and avoided Reason the Second.
Reason the Second : Setting up subdomains in a development environment (like on your localhost or svn) is a complete and total pain in the ass. Version control is a must in any serious web development environment and so it’s important that you can recreate all the things you have on your live server on your development setups. Unfortunately, with subdomains you can’t do this easily on a localhost and it’ll usually result in you having to 1) buy another domain to test these subdomain accounts and 2) branch out your code to behave differently (set a specific account as the default) when its working on a localhost. It’s not ideal and results in extra time being wasted when you’re trying to debug and test.
In the end, working with subdomains as a way to set up user accounts in a web application is definitely doable, but an experience we wouldn’t like to repeat again. We’ll try to share some tips on what we’ve done to lessen our pain down the road, but we’re still ironing them out to this day. If you can avoid them, please do because you’ll save yourself some money and some headaches.