I am thinking on deploying multiple (and different) web applications on the same server using the following schema:
www.mydomain.com/app1
www.mydomain.com/app2
Is this a good practice? Any recommendations?
I am thinking on deploying multiple (and different) web applications on the same server using the following schema:
www.mydomain.com/app1
www.mydomain.com/app2
Is this a good practice? Any recommendations?
If the applications are all related to the domain, I see no problem with doing things this way.
I don't see any glaring reasons why you should not do it this way. After all, not every website is dedicated to just a single task or application. Another approach would be to use subdomains, like:
app1.mydomain.com
app2.mydomain.com
Yahoo and Google both use these, for example. The folder approach is a good way to get things up and running for testing though.
Only downside to that approach is that you'll need to put some redirection or reverse proxying if any of the apps end up moving to a different server, whereas with a subdomain you would just need to change the A record for movedapp.domain.com.
So, to make it future proof, I'd create the subdomains.
You don't mention any technology, but if you happen to be using Java for this, the web apps (by default) won't be sharing any session information. This can notably be an issue if you want a user to log in to one web app and also be logged in to the other web app.
Some containers (Tomcat, Glassfish) have single sign on available as a implementation specific feature.
Just an FYI of some of the ramifications of the decision.
My usual approach would be to treat a site as serving a single purpose. "Single" actually defines a broad goal and usage pattern here. If the multiple applications all fit in together and synergistically work towards the site's single purpose, then
mydomain.com/app1 and mydomain.com/app2 is pretty fine.
It means they exist and live to augment the main site.
If the applications have nothing much to do with each other and pretty much live in their "own world" then they probably ought to exist as their own sub-domains.
app1.mydomain.com and app2.mydomain.com
this allows you to setup your DNS strategy to different IP addresses (web servers/farms) instead of bunching them together in the same pool.
One reason is if you wanted to support SSL connections to your web server.
If you use the folder based approach then you don't have any issue with SSL certificates.
If you go for the subdomain method (app1.mydomain.com, app2.mydomain.com, etc.) you will probably need a wildcard SSL certificate which will be more expensive, or multiple certificates.
Not an issue if you don't need SSL or have few applications that require it.