Prev: Unstoppable Script Execution
Next: Web application architecture (subdomain vs. subdirectory)
From: Nathan Nobbe on 25 Aug 2010 15:28
On Wed, Aug 25, 2010 at 1:20 PM, Shreyas Agasthya <shreyasbr(a)gmail.com>wrote:

> I am not sure who the end-users are for your website but if you are
> concerned about scalability, I would definitely go for a sub-domain
> approach. Assuming you approach a CDN like Akamai and you want to offload
> the traffic to come from the cloud, it's lot easier for you to integrate
> with them and to maintain.
>
> The subdirectory approach, whereas, is very cumbersome and takes more work
> at your end to paraphrase the whole set-up should the needs change going
> forward.
>

bearing in mind you can take a mix-&-match approach here to avoid insanity.
for example on your 'main app' you have a homepage, a user profile page,
and a cart page, for conversation sake.

again taking blah.com as an example a simple (sane) approach would be

blah.com/home
blah.com/profile
blah.com/cart

then imagine you store images on s3, so you have images.blah.com. this is
easily incorporated into any of the above urls by simply having image tags
with urls of image.blah.com/imageName. no need to have home.blah.com here
for example unless the webserver infrastructure was distributed, and even
then load balancers could be used to eliminate the call for that.

like i was saying youd typically only see this on a big site which operated
under an SOA paradigm. take facebook for example, they will have clusters
of infrastructure for image management, advertising, search etc. etc.

for a simple site sub-directories is the obvious route for a contiguous
single application. this really is a question of how large is the site, and
what are the load / distribution requirements, IMO.

-nathan
From: Tim Martens on 25 Aug 2010 17:45
Thanks for all your answers. To clarify my question, I'm looking for advice
regarding how best to set up users for a web app, e.g., username.myapp.comvs
myapp.com/username and the pros and cons of each. All users will be using
essentially the same app that will have their data in their account. I can
see the logic of setting up subdomain for things like a universal login and,
say, metrics for example.

Is javascripting more difficult across subdomains? Is one approach beter in
terms of security? Essentially the entire app will be running on https.

Thanks again!

Tim

On Wed, Aug 25, 2010 at 2:07 PM, Nathan Nobbe <quickshiftin(a)gmail.com>wrote:

> On Wed, Aug 25, 2010 at 12:45 PM, Tim Martens <tim.martens(a)gmail.com>wrote:
>
>> 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 -- is this but a trebd? --
>> 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.
>>
>
> subdomains are useful for separating out various applications on a site.
> for example, suppose you have a client facing application w/ a backend,
> then a separate application for coordinating development of this app, trac
> for example. say your main url is blah.com.
>
> for the main app you might just take your blah.com proper (this is
> typical), then for the trac site you have trac.blah.com. within each of
> these applications the subdirectory approach is taken.
>
> basically if you were to use a subdomain approach for a single app it would
> typically need to be massive to rationalize (unless youre insane). lots of
> large sites use subdomains to implement distribution. say you have a big
> image hosting site, all the images are stored on s3, so you might have
> images.blah.com in that case (note the images are hosted on separate
> infrastructure).
>
> just general guidelines, quite vague, but hopefully helpful.
>
> -nathan
>
From: Per Jessen on 26 Aug 2010 02:08
Tim Martens wrote:

> Thanks for all your answers. To clarify my question, I'm looking for
> advice regarding how best to set up users for a web app, e.g.,
> username.myapp.com vs myapp.com/username and the pros and cons of
each.

Using username.myapp.com means defining that name in your DNS and havin=
g
a separate virtual host definition in your apache config.=20

Using myapp.com/username means having one virtual host, and no extra DN=
S
records.=20

One is not necessarily better or worse than the other - to me it's
mostly about presentation and I would go for the myapp.com/username
option. This (in my mind) puts "username" a level lower than "myapp",
whereas username.myapp.com does the opposite.=20


--=20
Per Jessen, Z=C3=BCrich (17.7=C2=B0C)

From: Per Jessen on 26 Aug 2010 02:09
Shreyas Agasthya wrote:

> I am not sure who the end-users are for your website but if you are
> concerned about scalability, I would definitely go for a sub-domain
> approach. Assuming you approach a CDN like Akamai and you want to
> offload the traffic to come from the cloud, it's lot easier for you t=
o
> integrate with them and to maintain.
>=20
> The subdirectory approach, whereas, is very cumbersome and takes mor=
e
> work at your end to paraphrase the whole set-up should the needs
> change going forward.

The subdirectory approach is easily rewritten to an internal subdomain
structure.=20



--=20
Per Jessen, Z=C3=BCrich (17.7=C2=B0C)

From: Peter Lind on 26 Aug 2010 02:37
On 26 August 2010 08:08, Per Jessen <per(a)computer.org> wrote:
> Tim Martens wrote:
>
>> Thanks for all your answers. To clarify my question, I'm looking for
>> advice regarding how best to set up users for a web app, e.g.,
>> username.myapp.com vs myapp.com/username and the pros and cons of
> each.
>
> Using username.myapp.com means defining that name in your DNS and having
> a separate virtual host definition in your apache config.
>

While offtopic and nothing to do with PHP I think this should be
corrected: you can set a *.yourdomain rule which matches all
subdomains not explicitly set. So no, you do not need to define every
single name as a DNS record.

Regards
Peter

--
<hype>
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
BeWelcome/Couchsurfing: Fake51
Twitter: http://twitter.com/kafe15
</hype>
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Unstoppable Script Execution
Next: Web application architecture (subdomain vs. subdirectory)