3

We are working on a large scaled web app that built on top of javascript frameworks and libraries (node, express/sails, angular, mongo etc).

We need to have a backend that from one hand serve the web application but on the other accept API calls for data (from the same app but from other origins as well) - very common these days.

One of the decision we want to take is should we separate the backend for Web Application server and API server or put them together.

For example should we have an express running serving both or should express serve the web app, static content, auth etc and have a separate Restify server serving the data.

What are the pros and cons for each agenda?

Travis Webb
  • 14,688
  • 7
  • 55
  • 109
Ben Diamant
  • 6,186
  • 4
  • 35
  • 50

1 Answers1

6

A clean separation of concerns is always the way to go. If, as you said, your API-Server takes calls also from other Apps, I would suggest you separate the delivery of static files and your API. It leaves your more flexible in changing the way one or the other works. Another benefit is that your API only needs to worry about API Calls and not the delivery, which should make it answer even faster.

I'm gonna take this one even further and say: Use nginx to deliver your static Web-App files (if you are not working with server side templating). See also this Thread - nginx is faster with delivering static sources.

In my company, this is how we do it for every App and it turned out to work just great.

So the Pros:

  • Better performance for both - static delivery and API
  • Clean separation of concerns
  • More flexibility in changing one or the other

The only con is that you need to install and maintain two programs. But given that NodeJS is super easy to set up, that shouldn't be a showstopper.

EDIT As state by mnemosyn in the comments, if you separate your apps, you should still pull every request through the nginx Server to avoid some same-origin-policie issues. Within your nginx, you just have to configure a virtual-host pointing to your NodeJS-App and then proxying all request to a specified path (for example /api/) to that VHost. You can read about it here.

Community
  • 1
  • 1
David Losert
  • 4,652
  • 1
  • 25
  • 31
  • 3
    Don't forget the same-origin policy: Performing requests across sites is complicated. You'll have to set CORS headers everywhere, can't use X-headers without additional preflight requests that can't be cached, DELETE and PUT require additional care, there are more DNS requests, etc. I wouldn't say this is so clear-cut. If the other clients are web clients, too, there's no additional overhead. But if the other clients are server clients, the additional work is huge. – mnemosyn Mar 08 '15 at 10:31
  • 2
    uh right, I forgot to write that you should proxy every request through NGINX to exactly avoid that. Gonna add that. – David Losert Mar 08 '15 at 10:34
  • Thank you for commenting, we were thinking about node for webapp because above static file serving we need it for authentication views and logic. But agree with the pros for nginx – Ben Diamant Mar 08 '15 at 11:38