Ability to set ROOT_URL_PATH_PREFIX for cdn/serving files statically?

[James Gill]

We're trying to serve our static files via CDN and/or nginx for speed and performance.  One of the hurdles is that the bundled JS/CSS files are linked as `/03A73Ewhatever.js`, which makes them hard for nginx to identify, and harder to direct through a CDN.  What we'd love to be able to do is have those files be linked as `/bundle/03A73Ewhatever.js`, which would allow nginx to handle them intelligently, and/or as `http://my.cdn.com/03A73Ewhatever.js`.

Currently, meteor prefaces those with `##ROOT_URL_PATH_PREFIX##`, which it substitutes from `__meteor_runtime_config__.ROOT_URL_PATH_PREFIX`.  This, in turn, is set by the pathname of `ROOT_URL`.  But since `ROOT_URL` is used for other purposes (like oath callbacks) I don't want to pollute it with cdn/nginx specific details.  I'd like to be able to set `ROOT_URL_PATH_PREFIX` similar to `ROOT_URL`.  In effect, I want to change the lines in packages/meteor/url_server.js from

  var pathPrefix = Npm.require('url').parse(__meteor_runtime_config__.ROOT_URL).pathname;

  __meteor_runtime_config__.ROOT_URL_PATH_PREFIX = pathPrefix === "/" ? "" : pathPrefix;

to

  var pathPrefix = process.env.ROOT_URL_PATH_PREFIX || Npm.require('url').parse(__meteor_runtime_config__.ROOT_URL).pathname;

  __meteor_runtime_config__.ROOT_URL_PATH_PREFIX = pathPrefix === "/" ? "" : pathPrefix;

This would be a great help for us in terms of scaling.  If there's some other way that this can be done, we're happy to hear.  We're also happy to submit a PR.  Or bring a special hot sauce to whoever implements it.

James

[Adrian Lanning]

Hi James,

I'd also like to figure out a better story for deploying assets on a CDN.

Here's a patch that makes your suggested change:

  https://gist.github.com/alanning/7642166

(We apply our patches as part of our deployment process.)

You can see it in action like so: 

meteor create --example leaderboard

cd leaderboard

meteor bundle bundle.tgz

tar xf bundle.tgz

<download gist to root_url_path_prefix.patch>

patch -p0 < root_url_path_prefix.patch

<start local mongod instance in another terminal>

ROOT_URL_PATH_PREFIX=/bundle ROOT_URL=http://example.com/ PORT=3000 MONGO_URL=mongodb://localhost:27017/meteor node bundle/main.js

<point browser to http://localhost/bundle>

There are a few issues:

* Root app is now served from http://localhost/bundle

* Using an absolute url for ROOT_URL_PATH_PREFIX results in the following error being thrown:

/Users/alanning/src/js/meteor/leaderboard/bundle/programs/server/boot.js:185

}).run();

   ^

Error: a route URL prefix must begin with a slash

    at _.extend.declare (packages/routepolicy/routepolicy.js:95)

    at new StreamServer (packages/livedata/stream_server.js:23)

    at new Server (packages/livedata/livedata_server.js:990)

    at Package (packages/livedata/server_convenience.js:10)

    at packages/livedata.js:3919:4

    at packages/livedata.js:3930:3

    at /Users/alanning/src/js/meteor/leaderboard/bundle/programs/server/boot.js:154:10

    at Array.forEach (native)

    at Function._.each._.forEach (/Users/alanning/src/js/meteor/leaderboard/bundle/programs/server/node_modules/underscore/underscore.js:79:11)

    at /Users/alanning/src/js/meteor/leaderboard/bundle/programs/server/boot.js:81:5

[James Gill]

The reason the app is sourced from /bundle is that packages/webapp/webapp_server.js checks for ROOT_URL_PATH_PREFIX in the incoming url.  So perhaps we shouldn't try to re-purpose an existing variable.  A different hack that (is very hacky and) works is to create a new variable STATIC_PREFIX that is put instead of ROOT_URL_PATH_PREFIX in app.html.  I added a line at packages/meteor/url_server.js line 6:

  __meteor_runtime_config__.STATIC_PREFIX = process.env.STATIC_PREFIX;

And changed line 422 of packages/webapp/webapp_server.js to:

      __meteor_runtime_config__.STATIC_PREFIX  ||

        __meteor_runtime_config__.ROOT_URL_PATH_PREFIX || "");

Then, running the meteor bundle with `export STATIC_PREFIX=/bundle`, and adding an nginx conf directive

#Serve the meteor bundled js/css files

location /bundle/  {

  alias /path/to/current-deploy/bundle/programs/client/;

}

seems to work.  Obviously just ignoring ROOT_URL_PATH_PREFIX in favor of STATIC_PREFIX is not good, but it might point the right way forward.

I haven't tested STATIC_PREFIX with a CDN (ie, absolute url) yet.  Hopefully it just works...

Also, this is probably a n00b question, but how do I easily run a custom fork of meteor?  I'd love to get a patch of the bundled code, like you did.  I used to just change smart.json, but I don't think that's supported anymore?

James

[David Glasser]

To your last question about running from a fork: for a while now, actually running the meteor through mrt has been unnecessary.  ie, you still need to use mrt for things dealing with installing atmosphere packages like "mrt add", but once the package is in your app, just running "meteor" directly works (and is what I personally recommend).

So how do you run from a custom fork? Just clone the meteor repo, and run the meteor shell script that's inside it instead of mrt or your installed meteor.

--
You received this message because you are subscribed to the Google Groups "meteor-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-core...@googlegroups.com.
To post to this group, send email to meteo...@googlegroups.com.
Visit this group at http://groups.google.com/group/meteor-core.
For more options, visit https://groups.google.com/groups/opt_out.

[Arunoda Susiripala]

One note on mrt. We can define git fork info into smart.json. So with that, we dont need to worry about getting the fork. This is very important specially, if we are working in a team. 

--

You received this message because you are subscribed to the Google Groups "meteor-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-core...@googlegroups.com.
To post to this group, send email to meteo...@googlegroups.com.
Visit this group at http://groups.google.com/group/meteor-core.
For more options, visit https://groups.google.com/groups/opt_out.

--
Arunoda Susiripala

@arunoda

https://github.com/arunoda

http://www.linkedin.com/in/arunoda

[Tom Coleman]

Yes, Arunoda is right. It’s really important for teams. 

You can get a custom fork with (in your smart.json):

{

  “meteor”: {

    “git”: “https://github.com/user/meteor.git”,

    “branch: “a-branch-if-you-use-one”

  }

}

What’s no longer supported is a “path” definition for the Meteor executable because the use case was less clear. You can track it here: https://github.com/oortcloud/meteorite/issues/148

Tom

[Emily Stark]

James's non-denominational holiday present: https://github.com/meteor/meteor/commit/6eccf8cbbb074bd750851a3f75595011aa7533ed

But I request chocolate as my reward rather than hot sauce.

On Monday, November 25, 2013 6:57:58 AM UTC-8, Adrian Lanning wrote:

[Gabriel Engel]

Hi,

I am trying to solve a similar issue, but in my case I am using AWS Cloud Front as my CDN. 

As a resul, all my static cacheable files from http://www.perdigueiro.com.br/ are automactly fetched and cached on http://cdn-www.perdigueiro.com.br/

So my idea was just to be able to set up a environment variable on the production server so it would add the CDN domain in front of all the static cacheable files that meteor uses. I already use my own variable so I can add it to the src of images on my templates, but it make appcache useless.

Is there something already thought or developed among those lines? Or could/should I try to develop this features and submit a pull request? Any recommendations/directions on where to start?

Thanks in advance for any info, and thanks for the amazing framework!

Cheers,

Gabriel Engel

[Gabriel Engel]

Hi,

I am trying to solve a similar issue, but in my case I am using AWS Cloud Front as my CDN. 

As a resul, all my static cacheable files from http://www.perdigueiro.com.br/ are automactly fetched and cached on http://cdn-www.perdigueiro.com.br/

So my idea was just to be able to set up a environment variable on the production server so it would add the CDN domain in front of all the static cacheable files that meteor uses. I already use my own variable so I can add it to the src of images on my templates, but it make appcache useless.

Is there something already thought or developed among those lines? Or could/should I try to develop this features and submit a pull request? Any recommendations/directions on where to start?

Thanks in advance for any info, and thanks for the amazing framework!

Cheers,

Gabriel Engel

On Friday, December 6, 2013 2:29:06 AM UTC-2, Emily Stark wrote: