Routes or subdomains for multiple apps?

Question

I have been looking online for some time but unable to find a definitive answer to this in terms of best practice and extracting the pro's and cons has been difficult.

I have multiple apps / locations that I wish to serve via an nginx reverse proxy

app1 is pure static files i.e. js/html/css etc app2 and app3 are wsgi applications

My current solution uses subdomains to differentiate in terms of routing

example.com -> app1
app2.example.com -> app2
app3.example.com -> app3 

Then I have different server blocks in my nginx configuration for each application based on server name.

This works well, however I am aware of the alternative of achieving the split via routes i.e.

example.com/ -> app1
example.com/app2/ -> app2
example.com/app3/ -> app3

Which is better practice? the lack of subdomains makes CORS/Session cookie management easier as well as not requiring multiple DNS records for the subdomains. Are there downsides to the route approach? Both these approaches seem to be implemented around the web so what is the deciding factor.

Answer 1

Personally I prefer example.com/app1 , example.com/app2 or maybe even on a deeper level, example.com/portal/app[1-N] to app1.example.com and app[2-N].example.com as to me that appears completely seamless.

But many application developers write code with the assumptions that:

• theirs is the only application will be deployed
• their application will always be deployed in the root of an URL

And that will cause issues when you then have to use reverse proxy rules on an URL path that is below the level of the root /.

You are likely have several different applications that all use the same base URL's such as /js/ /images/ /css/ etc. with absolute links to resources those base directories in their HTML.

Much easier is to simply map a complete subdomain to a single application.

Example

app1 is running on appserver1
app2 is running on appserver2

and in the nginx configuration you have two reverse proxy blocks to map those applications into the URL space of example.com as example.com/app1 example.com/app2

server {
    listen 80;
    server_name example.com;
    root /var/www/html ; 
    location /app1/ {
         proxy_pass http://appserver1/; 
    }
    location /app2/ {
         proxy_pass http://appserver2/; 
    }
}

You can have the same absolute reference to for instance

<script src="/js/jquery.js"></script>

in both the HTML code of appserver1/index.html and appserver2/index.html.

When you request http://example.com/app1/index.html your browser will then try to load the script and request http://example.com/js/jquery.js and will happen then?

The URL /js/jquery.js might map to file in the local file system /var/www/html/js/jquery.js, or it will trigger a 404 not found error, but it will definitely not be reverse proxied to appserver1/js/jquery.js

The reverse proxy will not automatically rewrite the absolute URL "/js/jquery.js" to http://example.com/app1/js/jquery.js for app1 and neither will it do similar rewrite to http://example.com/app2/js/jquery.js for app2.

You can adjust for that but it is pain to set up and maintain.

Answer 2

server {
    listen 80;
    server_name example.com;

    access_log /var/log/nginx/example.com-access.log;
    error_log /var/log/nginx/example.com-error.log;
    #because logs are love
    location ~ ^/app3 {
        #--->app3
    }
    location ~ ^/app2 {
        #---> app2
    }
    location / {
        #----> app1
    }
}

This should be the general 1 serverblock-multiple location configuration.