Multiple apps in /app1 /app2 ... /appX fashion

help
1

It is very likely this question has been answered already, however, I am attempting to run multiple, independent apps from within single domain www.example.com and I wish they would be available as /app1 /app2 …

I have successfully deployed the first app to my customized droplet on DigitalOcean. However, the app was bound to the root of the domain, that is www.example.com/

I have experimented with ROOT_URL parameter and some basic modifications to the custom virtual host config file for NGINX, and was able to push the app to the address www.example.com/app1

However, a problem remains with linking the assets in the Public directory of my app. (These are just some web fonts and few helper images).

Is there a convenient way or a concise strategy to handle installation of individual meteor apps in a /app1 /app2 ... /appX fashion?

1 Like
2

EDIT:
I may have misread the issue, just realised you’ve managed to get the app running in a subfolder already. You may be having issues with relative paths. E.g. <img src="/images/image.png"> points to http://domain.com/images/image.png instead of http://domain.com/app1/images/image.png.

You probably want to use http://docs.meteor.com/#/full/meteor_absoluteurl to replace all your relative paths. I would create a spacebars helper with http://docs.meteor.com/#/full/template_registerhelper to do something like:

{{absoluteUrl "/images/image.png"}}

Meteor.absoluteUrl will use ROOT_URL to create the correct path for your app.

Old answer below in case anyone finds it useful…

You’ll need to use haproxy or nginx for this. I won’t go into detail because it’s non-trivial and there’s a lot of information out there on the net but basically you run each app on a different port:

For example:

App1: localhost:3000
App2: localhost:3100
App3: localhost:3200
App4: localhost:3300

With haproxy you can add rules like:

frontend default
    bind :80
    acl app1 path_beg /app1
    acl app2 path_beg /app2
    acl app3 path_beg /app3
    acl app3 path_beg /app4

    use_backend app1_backend if app1
    use_backend app2_backend if app2
etc...

backend app1_backend
    server app1_1 localhost:3000

backend app2_backend
    server app2_1 localhost:3100
etc...

Hope this helps, as I say it’s something you probably want to do a bit of research into. Some potentially useful links if you go down the haproxy route:


http://seanmcgary.com/posts/haproxy---route-by-domain-name
http://cbonte.github.io/haproxy-dconv/configuration-1.5.html (Official docs, make sure you’re looking at the right version of the docs depending on which version of haproxy is installed)

1 Like
3

Dear @mjmasn thank you very much! Indeed, the suggestion to use spacebars helper sounds reasonable! As for the server-side configuration, I have been following the official guide from DigitalOcean, and it worked like a charm!

4

The strategy proposed by you, @mjmasn does work for all types of assets directly referenced from within separate template files. I have successfully created a global helper that can assist in rewriting correct URLs.

However, the problem remains with the assets, which one would like to reference from the public folder. To be more specific, I have few fonts, which are directly referenced from within css files.

I could expect, that the easiest solution would be simply modify all the references in css files thinking of link structure on the production server, however, this would disable correct rendering and referencing of fonts on my local development machine. Once again, big thanks for help. Is there a convenient way to deal with that?

5

Ah I see. I think the CSS is always loaded in the root directory e.g. http://mydomain.com/app1/somerandomfilename.css

The problem again is stuff like:
background-image: url('/images/image.png');

You should be able to change this to:
background-image: url('images/image.png'); <-- note the lack of leading forward slash

This also works in html but if your page is domain.com/app1/something/page, then “images/image.png” refers to domain.com/app1/something/page/images/image.png. As the css is always served from the root directory (and references in the css are relative to the css file itself) you avoid this problem.

Hope that makes sense :slight_smile:

2 Likes
6

It does make a lot of sense of course. Thank you for your effort. I am perfectly aware it is very difficult to come out with generic solutions for very specific problem like linking within CSS. I will need to do some decent tinkering in the code of my first app and figure out the best ways to reference the static assets.