Serving my angularJS web app static content, nodeJS or apache?

Question

I'm developing a web app, the client side is an angularJS application designed to consume My REST server-side API, so all my files in my public directory are static.

I would like to try out NodeJS + express to make my server side API since I have heard so much of it, I went over many tutorials and now i understand how to go about making the API.

But I dont understand why serving my static files feels so complicated, I have used the LAMP stack a lot and serving static content using it is dead easy, not even 1 line of code. using node it seems that i will have to write routes for every file?

I have read about people using apache to serve the static content and have the app reference node, how can that be done? can i just point my client side ajax requests to a different port and have node running on that port on the server, or would i need another ip?

what's the best practice on this?

Answer 1

Serving static files on nodejs is super easy, simply add all those files to a public folder and add the following middleware to your express app:

app.use(express.static(__dirname + '/public'));

where __dirname + '/public' is the path to your public folder. That's it, one line of code.

Answer 2

Apache would likely be more performant than node.js. Apache specifically would have more overhead. Typically I use nginx for this kind of thing. In your case its also possible to upload all your assets to a CDN as your assets are static.

One problem with static file serving from nodejs is it doesn't handle things like caching, cache-control, url_rewriting, and provides security from DoS attacks. I'd really recommend using nginx in production for serving static assets, or a CDN, possibly a combination of the 2. You wouldn't want to serve your assets from your API, its good to have a clear separating line so you can scale each individually, as its likely your API will need to scale sooner.

Something like Nginx will most certainly perform better under load. The only advantage to using express is its easier to setup. However you only have to set up nginx once and then you just deploy to your configured web root. Apache will probably also handle the load better, but isn't as lightweight as it relies on an old method of forking processes to handle concurrency, where as Nginx is asynchronous much like node.js

Best practice is definitely to serve static files with something that is made to do so like nginx, a CDN, or another web server. In my opinion serving files from node.js is usually for small, low traffic websites. You can do exactly as you depicted. You can have your API on a different port. Whats most common is you have your UI at " http://mywebsite.com/ " and your api on a sub-domain " http://api.mywebsite.com/ ". However, if you're running both off the same machine using a different port might be easier than trying to configure both domains to the same box. In production I'd definitely keep both on port 80 and have a subdomain for the api.

As for veggiesaurus's answer, I don't agree. You'll usually run grunt/gulp/similar to minify and build your assets. You could simply build your assets to a specific webroot. You could then specify this web root in a config file or environment variable. I personally prefer building my application on the server, so I can build my project to its environment accordingly. The build script can also serve as a launcher for your app, or to create a init script for your system so you can make sure the app continues running and restarts if it crashes. It is messy to include you project builds in your repository, and if your build to a path outside of your project directory then you don't have to worry about git-ignoring your build. If you want to build in that directory you could simple configure your web root there, but I personally prefer not to.

Answer 3

If your files are all public, you can put them all in a public subfolder, and write a few lines of code in express and be done with it. You can see a guide here . As for making ajax requests to a different port, that would absolutely work. You would just have to ensure that you configure your express server to listen on that port.