Ways of serving static files


#1

Has anybody experience in serving static files from a remote server that is hosted by yourself?

I can’t use any external provider but have a lot of VM capabilities in our private computing cloud.

I would especially like to know

FS or DB?
Do you also use a minimal Meteor or other Node backend?
What were the biggest challenges you experienced?

I found a lot of articles on the net with many different ways of serving static assets so it would be great to see how people from the Meteor community approached this topic.


#2

i mostly just serve them from meteor, if its really static. If its user generated stuff, i upload them to AWS and server from there.


#3

I deployed on Digital Ocean. Used meteor-files to manage the upload and files collections for small json/geojson sample files. This package has a lot of easy integrations with AWS and similar, but i did not test it.

Honestly, my biggest challenge was to understand the better project structure and the best place to put files into, where the client could have access to them via a download route. After some struggle the package i mentioned worked like a charm


#4

i upload them to AWS

I have the requirements to not use an external service but host the file server on my own but for scaling issues I won’t serve them with the same Meteor instance but on a dedicated instance with the sole purpose of serving static files.


#5

I’m using nginx as a reverse proxy - basically, anything under http://foo.bar.baz/static gets served up by nginx directly while any other URL gets the Meteor instance.

While both (i.e. static files and Meteor) reside on the same server in my case, there’s nothing which prevents you from spreading things over several servers. This would probably be the easiest setup in your case and you can also use nginx for SSL.


#6

The configuration file to use nginx in front of the meteor app looks something like this:

server {

  # force redirect to https
  
  listen 80;
  server_name example.com www.example.com;
  return 301 https://$host$request_uri;

}

server {

  listen 443 ssl http2;
  listen [::]:443 ssl http2;
  charset UTF-8;
  server_name example.com www.example.com;
  
  # Meteor app (assuming is running on port 3001)
  
  location / {
    proxy_pass http://localhost:3001;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_cache_bypass $http_upgrade;
  }
  
  # Static assets
  
  location /static {
    root /path/to/folder/with/static/assets;
  }
  
  ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # managed by Certbot
  
}

In this case, all assets starting with /static will be served directly from nginx.


#7

As an addendum, in case anyone is wondering why /static is matched even though the equally matching / route comes before:

/ is a special case and will match only if there isn’t a regex route or “regular” but longer route.

In this case, /static is longer so it will take priority over /


#8

This is really helpful. Now one question to that - how would I have to configure the nginx if the static content would be served by another server and not from the same machine?

The other server (and the static files) would be available by a public IP that would be mapped to a subdomain like static.mysite.com in our DNS entry file.


#9

http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass

Basically, similar to what we’re already doing with serving Meteor content. Only you don’t need to fiddle around with the headers as much because your static content server won’t care as much.


#10

Thanks a lot to all of you. This is a good base to start into my work in the new year :slight_smile: