4 ms·

Web application architecture (subdomain vs. sub directory)

3 points by timpish 16y ago

Hi Everyone, I'm in the customer discovery phase for a Health IT web application concept I have. My programmer is new to web apps, but not to programming and is set up with LAM(PHP). Maybe we're a little old school, but it's proven. We're still debating weather to use a framework or to go with Rasmus's "no framework framework" approach. Language/Framework decisions aside... my main question is about subdomain (customerx.appname.com vs subdirectory (appname.com/customerx/) models for instances of individual customers' accounts. It seems most people are opting for the former, but I see flickr use the latter. The guys at Particletree (i.e., Wufoo) wrote a blog post about it (http://particletree.com/notebook/subdomains-development-sucks/) years ago to which they still attest. They say the subdirectory model is much easier and faster to develop and deploy. We are developing locally on our macs and using hosted CVS. I'm really lost on this issue as all my searches turn up stuff on SEO/SEM. Is one approach easier that the other? What about security and scalability considerations? I would very much appreciate your opinions as to the pros and cons of each approach. As an aside, does anyone have some advice about rapid PHP deployment, i.e., pushing new features to production daily in micro iterations vs the typical milestone approach? Are there any good tools for this? What about hosts? Thanks all, Tim

jokull 16y ago
I think the subdomain approach is quite nice when the user account has a published component (think Posterous/Blogspot, not Gmail).
- timpish 16y ago
  Good point. In my case, it's really more document management based, i.e., each app instance (customer) has many clients whose private data they will be managing after it has been posted.
mishmash 16y ago
Three nice things about using subdomains are that you can: a) point a single account's DNS to an entire server (or cluster) without forcing all traffic to a specific machine or proxy b) offering custom domain names to customers is simply a matter of adding a DNS alias c) don't have customer URLs "polluting" your app's URL namespace At least IMHO, could be wrong though. :) edit: abcs
- timpish 16y ago
  so does point a) imply that scaling/load balancing is easier with subdomains? Is "adding a DNS alias" easy to do on a localhost or would it require a different scripting than on a live server?
tnorthcutt 16y ago
Speaking from a customer/user perspective: for things where I'll want to interact with other users/customers of the app and where there will be a publicly visible page (i.e. flickr, twitter) it seems to make more sense to use directories. For things where it's more of an internal use only and not visible without being logged in (basecamp, for instance), subdomains seem right. I think that's partly because of precedent from those widely used services, and partly because subdomains feel more private/secure.
- timpish 16y ago
  I agree somewhat, but I think it's mostly due to precedence. There are plenty of examples of URI component set ups that are (and feel) secure (gmail on https for one).
konad 16y ago
* Your SSL certificate will be considerably more expensive for a wildcard * URI components have a wider scope of acceptable characters than domains, plus uri escaping e.g. spaces with a %20 * subdomains can be traffic shaped / cluster managed using IP addresses (until you run out if IPs) * URI components can be traffic shaped using internal IPs via your web server * In my experience it's easier to mod-rewrite and pass $1 than a DNS and parse a hostname I remember lots of people going with subdomains that have since switched to URI components, particularly http://news.bbc.co.uk/ http://news.bbc.co.uk/ now goes to http://www.bbc.co.uk/news/ http://www.bbc.co.uk/news/ I would say that it is easier to categorize as one drills down. It is a shame that domains ended up backwards or else it would make more sense - http://uk.co.bbc/news http://uk.co.bbc/news So my personal preference is for URI components
- mishmash 16y ago
  > * Your SSL certificate will be considerably more expensive for a wildcard Very good point. Went with DigiCert for a wildcard a few years ago and it was in the $400-range compared to ~$100 for a standard cert.
  - timpish 16y ago
    Wildcards have come down a lot in price. I think you can get one for about $200 now. I'll probably need one anyway since nearly the entire service is going to be on https
- kls 16y ago
  Don't forget cross-site scripting if you go with any RIA web apps on the domain. I hate that one, because I would love to put all of my services on services.mydomain.com and get them out of the general app space, but it creates such a pain with scripting that it is not worth it.
  - timpish 16y ago
    How is this different with an RIA vs non-RIA web app? You mean like something in Flash or Flex vs HTML? Not sure I get what you mean. Are you saying it's more work for a localized app (coolapp.com/customer1/) to interact with services.coolapp.com than with coolapp.com/customer1/services. And does the latter imply that there would be massive redundancy or can one go about routing queries to avoid that?
timpish 16y ago
Thanks for all your comments! Is there an argument to be made in favor of either approach as regards security? I was thinking of a URI component structure that would use each customer's office address/credentials (gathered at sign up) e.g., coolapp.com/john/doe/MD/Newton/MA/02158/

3 points by timpish 16y ago

jokull 16y ago

I think the subdomain approach is quite nice when the user account has a published component (think Posterous/Blogspot, not Gmail).

timpish 16y ago
Good point. In my case, it's really more document management based, i.e., each app instance (customer) has many clients whose private data they will be managing after it has been posted.

mishmash 16y ago

Three nice things about using subdomains are that you can: a) point a single account's DNS to an entire server (or cluster) without forcing all traffic to a specific machine or proxy b) offering custom domain names to customers is simply a matter of adding a DNS alias c) don't have customer URLs "polluting" your app's URL namespace At least IMHO, could be wrong though. :) edit: abcs

timpish 16y ago
so does point a) imply that scaling/load balancing is easier with subdomains? Is "adding a DNS alias" easy to do on a localhost or would it require a different scripting than on a live server?

tnorthcutt 16y ago

Speaking from a customer/user perspective: for things where I'll want to interact with other users/customers of the app and where there will be a publicly visible page (i.e. flickr, twitter) it seems to make more sense to use directories. For things where it's more of an internal use only and not visible without being logged in (basecamp, for instance), subdomains seem right. I think that's partly because of precedent from those widely used services, and partly because subdomains feel more private/secure.

timpish 16y ago
I agree somewhat, but I think it's mostly due to precedence. There are plenty of examples of URI component set ups that are (and feel) secure (gmail on https for one).

konad 16y ago

* Your SSL certificate will be considerably more expensive for a wildcard * URI components have a wider scope of acceptable characters than domains, plus uri escaping e.g. spaces with a %20 * subdomains can be traffic shaped / cluster managed using IP addresses (until you run out if IPs) * URI components can be traffic shaped using internal IPs via your web server * In my experience it's easier to mod-rewrite and pass $1 than a DNS and parse a hostname I remember lots of people going with subdomains that have since switched to URI components, particularly http://news.bbc.co.uk/ http://news.bbc.co.uk/ now goes to http://www.bbc.co.uk/news/ http://www.bbc.co.uk/news/ I would say that it is easier to categorize as one drills down. It is a shame that domains ended up backwards or else it would make more sense - http://uk.co.bbc/news http://uk.co.bbc/news So my personal preference is for URI components

mishmash 16y ago
> * Your SSL certificate will be considerably more expensive for a wildcard Very good point. Went with DigiCert for a wildcard a few years ago and it was in the $400-range compared to ~$100 for a standard cert.
- timpish 16y ago
  Wildcards have come down a lot in price. I think you can get one for about $200 now. I'll probably need one anyway since nearly the entire service is going to be on https
kls 16y ago
Don't forget cross-site scripting if you go with any RIA web apps on the domain. I hate that one, because I would love to put all of my services on services.mydomain.com and get them out of the general app space, but it creates such a pain with scripting that it is not worth it.
- timpish 16y ago
  How is this different with an RIA vs non-RIA web app? You mean like something in Flash or Flex vs HTML? Not sure I get what you mean. Are you saying it's more work for a localized app (coolapp.com/customer1/) to interact with services.coolapp.com than with coolapp.com/customer1/services. And does the latter imply that there would be massive redundancy or can one go about routing queries to avoid that?

timpish 16y ago

Thanks for all your comments! Is there an argument to be made in favor of either approach as regards security? I was thinking of a URI component structure that would use each customer's office address/credentials (gathered at sign up) e.g., coolapp.com/john/doe/MD/Newton/MA/02158/