subdomain vs. subdirectory in web programming

Viewed 13782

There are two main strategies for handling multiple "applications" on the web:

  • subdomains (e.g. wiki.example.org, blog.example.org, admin.example.org, api.example.org/v1)
  • subdirs (e.g. example.org/wiki, example.org/blog, example.org/admin, example.org/api/v1)

What are the differences (advantages and disadvantages) of these two solution when dealing with web programming (e.g. in terms of code organization, browsers security models, javascript etc).

Edit: CW as there's a correct answer, but it's very broad.

10 Answers

Besides the fact that from a security standpoint it is a bit easier to isolate an app within a subdomain, I will just comment on what I think is the biggest difference between the two.

Pro's for subdomains:

  • You can isolate configuration (for for example apache) per-domain.
  • It will be easier to migrate parts of your application to other machines. Sub-directories won't really give you this flexibility.
  • Instead of having to use a $baseUri variable in every html template, you can just assume the root of the app is always /.

Cons:

  • It will be much more annoying to quickly setup staging or temporary development environments. For every 'app' you will now need DNS of hosts-file entries and webserver configuration. With subdirectories you could drop the app in a directory, and go!
  • If you do ever have the requirement to deploy your application on a different system where using / is because of some odd policy not possible, some rewriting might be in order.

My advice:

Make sure you can always do both, which will give you the best of both worlds. Every part of your app should have a configurable base uri that is always respected. As long as you make sure you can always go both ways, then who cares what you do? it's just a url and it can always be changed.

Personally, I prefer using a subdomain for each application, and then the sub-dirs (whether they are actually sub-directories or not -- preferably they are just re-routed to /index.php by a .htaccess) to denote different states of that application. For example:

admin.blah.com/users/1234/bob,
admin.blah.com/pages/4321/title,
blog.blah.com/archives/2007/5678/title, etc.

The subdomain tells you where you are, and the sub-directories tell you what you're doing.

  • In terms of code organization: The differences are nil, as you can map subdomains to any directory.
  • In terms of browser security: JavaScript access across subdomains is possible but has obstacles (see document.domain and consorts). I do not know of anything on the JavaScript side that is completely impossible when working with different sub-domains.

Opinion:

I personally tend towards directories and against subdomains for public addresses. The general public have become used to web addresses beginning with "www." and it creates unnecessary confusion to break this pattern. You will notice that very often people, when given a subdomain to type into the address bar, will automatically start typing in "www." and they will be surprised to learn that an address can be without.

To me, the only good way to use subdomains is for internal purposes to facilitate, or prepare for, the use of different servers (e.g. static.example.com, images.example.com etc.)

  • You can easily 'do' virtual servers on subdomains.
  • You can separate out subdomains to different cookies.

You'd be best off recognizing that subdomains are a "major" separation in Web space, and subdirectories a "minor" one. Subdomains are for, well, different domains; you could have different people running different applications on different subdomains. Subdirectories are partitions of a single (sub)domain, separating perhaps different applications by the same user.

Web standards are intentionally very open, but the more you abuse them to create strange hierarchies, the more that will bite you in the end.

One of the major advantages of sub-domains is the files they point to can be contained anywhere -- even on another server. My most common usage of a sub-domain is on going development of a live project. For example, you could create the sub-domain:

dev.example.com

and make a copy of your live site, including the entire directory structure. Drop in an .htaccess file to refuse connections from anyone but you and your client's IP, and use this to make changes until the updates are ready to be pushed live.

This is a pretty big topic, but here’s some thoughts on sub-domains...

Pros

  • Can use a ‘clean’ routing setup if you’re using MVC.

  • Very clear division between parts of the system and no danger of namespace overlap.

Cons

  • On the downside, there's likely to be more duplication of code on the backend, unless you're clever with library/includes directories and use a shared area.

From an SEO perspective, there's not a great deal of difference these days and indeed tools such as Google Analytics can be instructed to use a specific logging domain.

I personally use flask for development so it isnt much of a hassle to set one up(both)

Usually i go with sub directories but in some situations it is better to use subdomains

If you have subdirectories like host.tld/user/repository/commit/... Id rather go like user.host.tld/repo/commit

And i usually use sessions to redirect if they type the domain in another way

eg:I will redirect the if they typed it like host.tld/<user>/<repo>/<commit> to user.host.tld/repo/commit

Making it easier for the user meanwhile you can arrange your application in a better way

in short its really subjective

It depends on your preference. For SEO purpose, subdirectory is better to boost the domain authority.

Personally, I used subdirectories for different apps that are related while I used subdomain for static assets hosted on a different server to reduce the number of requests to the subdirectories.

Related