views:

35

answers:

1

So I am creating a web app, that will give each registered user a unique 'workspace'. This workspace should be accessible by anybody they give permission to.

I have the main domain for my marketing website, but I am trying to figure out how to manage the nitty-gritty domain management of the web app itself.

Should I buy generic domains that I then use to allow the users to chose one of them for their workspace, and create a unique subdomain there, or how should I approach this?

My web app is written in Rails.

A: 

The term Domain has a few meanings - I assume you mean "Domain" as in the hostname in a Domain Name or URL, also known as the "third-level domain name" (e.g: www.mysite.com - where mysite.com is the hostname).

I am trying to figure out how to manage the nitty-gritty domain management of the web app itself

I've usd 4th level domains before (also known as local hostnames, e.g: images.mysite.com, admin.mysite.com), but these were provisied via a helpdesk at the telco who managed the A-Records for our domain name, so it wasn't a quick and easy automated process.

I've also seen hosting firms provide web-based tools that allwo you to do this yourself - where they manage the A-Record.

In both cases management of the 4th level domains is performed manually. I haven't hread of anyone automating this within an app the have developed - it's obviously possible but definately non-trival.

Should I buy generic domains that I then use to allow the users to chose one of them for their workspace, and create a unique subdomain there, or how should I approach this?

It depends. Even if you host the application there's no reason why the client can't set-up a 4th level domain that points at your server and not their own; this would mean that your app would need to lookout for the 4th level domain only as there's no guaratee they'll be using a 3rd level domain your app "knows about".

Say John Brown from 'Studio ABC' signs up at mysite.com, what should I do? Give them studioabc.mysite.com or mysite.com/studioabc

It depends on what you want to achieve and what over-heads your comfortable with:

  • The "mysite.com/studioabc" option should be easy to auto-provision through your app, so in some ways that'd be easier to work with.
  • A problem with the "mysite.com/studioabc" option is that (depending on how much control you have over the web server) all your files (from all clients) will be in the same place - that will make it more complex to manage (back-ups, etc).
  • The "studioabc.mysite.com" is going to be harder and slower to provision (as DNS changes are required), but you have the advantage in that you can run them as seperate sites if you want to. For example, if "thebeatles.mysite.com" takes off you'd be able to move it to a different physcial web server that had better performance, but you can't move "mysite.com/thebeatles" so easily.

In both cases your app will be a Multi-tenanted one (except in cases such as studioXXX.mysite.com where the site is hosted elsewhere); data access becomes an issue - keeping the clients data separate. There's different approaches you can take for this, see this article on Multi-Tenant Data Architecture. (BTW - I know it's an MS article and you're working in Rails! - but it's an excellent article which will be helpful).

Buying a generic name is, well, generic. If you wanted to foster a community of clients around a particular thing then get a domain name that makes sense for that; if you use your own domain name it would in-effect be a form of advertising.

And rather than it being mysite.com, should it be obscuredomain.com that the actual web app resides at and therefore gives the subdomains of, because mysite.com is the marketing site.

I think either will work - the question is what do you think you're clients would prefer? How does that stack up with your business model? The domain name is an important part of any online presence (from a marketing side) as it helps define the identity of the site and those who use it - so choose carefully.

Do you ever want to sell this off? If you do you'd want to build it on a domain name that you were happy to sell with it. So with that in mind I'd have a domain name for your product / service and a seperate one for your business - assuming that you'd one day want to sell the site but not your business. Alternatively, if the website is the business and you're happy to sell them as a whole package then I'd put it all under the same domain name.

Finally, you might have more than one domain, each providing a different level of service (and each could have 4th level domains hanging off it instead of www):

  • www.mysite.com
  • www.mysitepremium.com
  • www.mysitecheapskate.com
Adrian K
Thanks for the feedback, but I think you misunderstood what I asked. What I wanted to know was how to structure the architecture on the web app side. Say John Brown from 'Studio ABC' signs up at mysite.com, what should I do? Give them studioabc.mysite.com or mysite.com/studioabc. And rather than it being mysite.com, should it be obscuredomain.com that the actual web app resides at and therefore gives the subdomains of, because mysite.com is the marketing site. I hope that makes sense.
marcamillion
Ok Adrian. Thanks for taking the time to write this. Will continue exploring my options.
marcamillion