How to host a node.js app on a server

[Mark Nutter]

I'm just getting into node.js and I haven't been able to find any
guides on how to actually setup a node.js server on a linux server, in
my case a slicehost slice. I'm no sysadmin expert, I just used
passenger/apache and the guides on Slicehost to get my rails apps up
and running. So how would I get an example node.js app running and
available on a subdomain, accessible from the web? Is this done in
apache? Or are there other ways to get subdomains or domains to
listen to port 8000. I just want to get an example up and running
somewhere other than my local machine. Big time noob here, some
guidance would be very appreciated.

[Joshua Kehn]

Mark-

If you want to access it via a domain name you need to alter the DNS settings, that isn't an apache thing.

The port it listens on is setup within the node application.

Can you more clearly define the issues you are encountering?

Regards,

-Josh
____________________________________
Joshua Kehn | Josh...@gmail.com
http://joshuakehn.com

> --
> You received this message because you are subscribed to the Google Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com.
> To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
>

[Tiago Paiva]

Mark,

Follow the example in the documentation, run it using node in your slice and you can access it via IP.

Check the slicehost library to learn how to change your DNS settings.

Hope it helps.

Tiago Paiva

[Stephen Belanger]

Yeah, node serves itself. have a look at the docs for listen() in the http section and you'll see that you can specify a port AND hostname to define what requests it should reply to.

[Mark Nutter]

Thanks for the advice everyone, I'll monkey around with it and see
what happens.

On Sep 12, 1:11 pm, Stephen Belanger <cyruzdr...@gmail.com> wrote:
> Yeah, node serves itself. have a look at the docs for listen() in the http
> section and you'll see that you can specify a port AND hostname to define
> what requests it should reply to.
>
>
>
> On Sun, Sep 12, 2010 at 11:05 AM, Tiago Paiva <pix...@gmail.com> wrote:
> > Mark,
>
> > Follow the example in the documentation, run it using node in your slice
> > and you can access it via IP.
>
> > Check the slicehost library to learn how to change your DNS settings.
>
> > Hope it helps.
>
> > Tiago Paiva
>

> > On Sun, Sep 12, 2010 at 6:38 PM, Joshua Kehn <josh.k...@gmail.com> wrote:
>
> >> Mark-
>
> >> If you want to access it via a domain name you need to alter the DNS
> >> settings, that isn't an apache thing.
>
> >> The port it listens on is setup within the node application.
>
> >> Can you more clearly define the issues you are encountering?
>
> >> Regards,
>
> >> -Josh
> >> ____________________________________

> >> Joshua Kehn | Josh.K...@gmail.com

> >>http://joshuakehn.com
>
> >> On Sep 12, 2010, at 10:29 AM, Mark Nutter wrote:
>
> >> > I'm just getting into node.js and I haven't been able to find any
> >> > guides on how to actually setup a node.js server on a linux server, in
> >> > my case a slicehost slice.  I'm no sysadmin expert, I just used
> >> > passenger/apache and the guides on Slicehost to get my rails apps up
> >> > and running.  So how would I get an example node.js app running and
> >> > available on a subdomain, accessible from the web?  Is this done in
> >> > apache?  Or are there other ways to get subdomains or domains to
> >> > listen to port 8000.  I just want to get an example up and running
> >> > somewhere other than my local machine.   Big time noob  here, some
> >> > guidance would be very appreciated.
>
> >> > --
> >> > You received this message because you are subscribed to the Google
> >> Groups "nodejs" group.
> >> > To post to this group, send email to nod...@googlegroups.com.
> >> > To unsubscribe from this group, send email to

> >> nodejs+un...@googlegroups.com<nodejs%2Bunsu...@googlegroups.com>
> >> .

> >> > For more options, visit this group at
> >>http://groups.google.com/group/nodejs?hl=en.
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "nodejs" group.
> >> To post to this group, send email to nod...@googlegroups.com.
> >> To unsubscribe from this group, send email to

> >> nodejs+un...@googlegroups.com<nodejs%2Bunsu...@googlegroups.com>
> >> .

> >> For more options, visit this group at
> >>http://groups.google.com/group/nodejs?hl=en.
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "nodejs" group.
> > To post to this group, send email to nod...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > nodejs+un...@googlegroups.com<nodejs%2Bunsu...@googlegroups.com>
> > .

[MilesTogoe]

need some help and clarification here

we run our nodejs development apps on laptops without nginx so obviously it an be run only with node - our sites run only node apps with couchdb, display static images, link to twitter, video, however on our servers we're running nginx with virtual hosting on some (several different domains running different apps). (linode /  slicehost)

we're using nginx only because we were under the impression it's the correct way to do this - Actually our sites are loading static images slowly although we have tried to serve them directly in the config rather than go thru our Picard controllers

can we skip nginx altogether ?  will we be missing something ? 

judging by other posts I think several of us need some guidance here from those more knowledgeable in sys admin

[Mark Nutter]

Well, I played around a bit but didn't really get anywhere. I get that
node.js acts as the web server, but how do I setup DNS settings to
look at node? If it sounds like I'm not asking the right questions,
it's because I'm clueless when it comes to web servers. I stumbled
across this blog post which seems to walk through how to deploy a
node.js app on a linux server using Spark; is this pretty much how
it's done, or are there alternatives? Thanks again.

> >     On Sun, Sep 12, 2010 at 6:38 PM, Joshua Kehn <josh.k...@gmail.com

> >     <mailto:josh.k...@gmail.com>> wrote:
>
> >         Mark-
>
> >         If you want to access it via a domain name you need to alter
> >         the DNS settings, that isn't an apache thing.
>
> >         The port it listens on is setup within the node application.
>
> >         Can you more clearly define the issues you are encountering?
>
> >         Regards,
>
> >         -Josh
> >         ____________________________________

> >         Joshua Kehn | Josh.K...@gmail.com <mailto:Josh.K...@gmail.com>

> >        http://joshuakehn.com
>
> >         On Sep 12, 2010, at 10:29 AM, Mark Nutter wrote:
>
> >         > I'm just getting into node.js and I haven't been able to
> >         find any
> >         > guides on how to actually setup a node.js server on a linux
> >         server, in
> >         > my case a slicehost slice.  I'm no sysadmin expert, I just used
> >         > passenger/apache and the guides on Slicehost to get my rails
> >         apps up
> >         > and running.  So how would I get an example node.js app
> >         running and
> >         > available on a subdomain, accessible from the web?  Is this
> >         done in
> >         > apache?  Or are there other ways to get subdomains or domains to
> >         > listen to port 8000.  I just want to get an example up and
> >         running
> >         > somewhere other than my local machine.   Big time noob
> >          here, some
> >         > guidance would be very appreciated.
>
> >         > --
> >         > You received this message because you are subscribed to the
> >         Google Groups "nodejs" group.
> >         > To post to this group, send email to nod...@googlegroups.com

> >         <mailto:nod...@googlegroups.com>.

> >         > To unsubscribe from this group, send email to
> >         nodejs+un...@googlegroups.com

> >         <mailto:nodejs%2Bunsu...@googlegroups.com>.

> >         > For more options, visit this group at
> >        http://groups.google.com/group/nodejs?hl=en.
>
> >         --
> >         You received this message because you are subscribed to the
> >         Google Groups "nodejs" group.
> >         To post to this group, send email to nod...@googlegroups.com

> >         <mailto:nod...@googlegroups.com>.

> >         To unsubscribe from this group, send email to
> >         nodejs+un...@googlegroups.com

> >         <mailto:nodejs%2Bunsu...@googlegroups.com>.

> >         For more options, visit this group at
> >        http://groups.google.com/group/nodejs?hl=en.
>
> >     --
> >     You received this message because you are subscribed to the Google
> >     Groups "nodejs" group.
> >     To post to this group, send email to nod...@googlegroups.com

> >     <mailto:nod...@googlegroups.com>.

> >     To unsubscribe from this group, send email to
> >     nodejs+un...@googlegroups.com

> >     <mailto:nodejs%2Bunsu...@googlegroups.com>.

[Stephen Belanger]

nginx shouldn't be needed, though last I checked it was more suitable for serving static files, so often times people would serve a static.example.com domain via nginx and reverse proxy the top-level domain to node. It's not necessary to do it that way, it's just a helpful performance optimization if you expect to serve a large quantity of static files.

[aaronblohowiak]

These are the basic facts:

DNS is a service that translates a name to an IP address.
Node runs on a computer that has at least one IP address.
Node can open 1 or more ports on that IP address (for instance, port
80 or port 3000.)
Only one application can answer requests for a given IP address / port
combination.
Apache/nginx can accept requests on an IP/port combination and
dispatch them to other applications to handle (called reverse
proxying.)

Here's the long explanation:

If you have a domain currently pointing to the same IP address as the
IP that node binds to, then you can access it using that domain.

For instance, lets say you have a computer (server1) and it has the ip
address 4.2.2.1. On server1 you currently have apache bound to port 80
on 4.2.2.1. This means that any request coming in to that IP address
will be handled by apache. So, if you point your browser to http://4.2.2.1:80
(which is the default http port, so this is the same thing as http://4.2.2.1/)

If you start node on the same computer and tell it to listen to port
3000 on the ip 4.2.2.1, then if you point your browser to http://4.2.2.1:3000
then it will be handled by node.

Let's say you have a domain name, omgwtfbbq.com. When you register the
domain, you specify what computer is the DNS server for that domain
(frequently, you will use the same company as you used to register the
domain, but not always.) At the DNS administration screen, you should
have the ability to add records. For now, we'll just talk about "A"
records. an "A" record is a lookup table from a name to an IP
(simplified, but this is mostly true.. there are extensions that will
only confuse things and you shouldnt need them.) If you have a DNS
entry that points omgwtfbbq.com to 4.2.2.1 and pants.omgwtfbbq.com to
4.2.2.1, then both names will point to the same computer. It is
common to use a wildcard ( *.omgwtfbbq.com ) to say that all
subdomains should point to the same address as the primary.

So, when you put in http://pants.omgwtfbbq.com in your browser, your
browser goes, sees who the DNS server is for that name, then goes and
asks the DNS server for that name what the IP address is for it. in
this case, it will "resolve" to 4.2.2.1. At this point, it is just
like you had typed http://4.2.2.1 in the browser, *except* that the
browser will send the name of the requested domain along with its
normal communication to the server.

Remember that the default port is port 80. So, if you have
http://pants.omgwtfbbq.com and http://omgwtfbbq.com pointed to the
same IP address, then they will both resolve to 4.2.2.1 on port 80.
Since only one application can bind to a port on an ip address, you
run into a bit of a situation if you want to have different domains on
the same port on the same computer.

The easiest way around this is to use another port. So, if you run
node and tell it to listen on port 3000, then you can access
http://omgwtfbbq.com:3000/ or http://pants.omgwtfbbq.com:3000/ and
both requests will be handled by node (because they resolve to the
same IP/port combination.)

There is no way to have a DNS entry point to a specific port!!!!!!!!!

So, how do you run multiple domains on the same IP address / port
combination? Well, you have to have a single application accept all
requests on that ip/port combination, and then it "proxies" the
request to other applications/processes, depending on the requested
domain (remember above where i said that the browser will send the
requested domain with its request to the server?) So, now we have at
least two pieces of software, the reverse proxy and the application
server that will actually handle the request. the reverse proxy
dispatches requests to the appropriate application server depending on
the domain used in the request.

You can use apache as a reverse proxy. You can also use nginx as a
reverse proxy. Some reverse proxies can also do things like serve
static files (like apache and nginx.) Some reverse proxies can load
in your application server so you don't have to run multiple
applications to make your site work, like apache has phusion
passenger, mod_php, or mod_perl.. it loads rails/php/perl and then
uses that bit of code to handle the dispatched request.

Node is cool because it can run without requiring a reverse proxy.
But, if you're going to share an ip/port combination between node and
something else (like php, perl, python, rails, java, whatever,) then
you're going to need a reverse proxy to accept all the incoming
requests and dispatch them to the appropriate back-end application.

WORD OF WARNING: there is currently no reverse proxy that works with
websockets. so for now, your node.js instance MUST NOT be run behind
a reverse proxy if you want to use websockets.

Does that clear things up for you?

- Aaron

[Mark Nutter]

Wow, thanks for the detailed response! Definitely helpful, very clear
now. I think it's time to finally sit down and really learn server
admin stuff (if you have any good book recommendations or resources
let me know).

So what you're saying is, nginx and apache are the things giving the
browser the proper website based on the domain name, even though all
the different domains are really sitting on one IP address. Node can
run behind a reverse proxy like these, but doing so will kill the
support for websockets (kind of destroying one of the main reasons for
using node).

So in order to get the full benefit of Node, I need to contact
slicehost and ask for another IP which I dedicated directly to my node
app. Am I on the right track?

Again, thanks so much, it can be difficult to break into this stuff as
a beginner sometimes, especially since the more entry-level the
question the less likely there are to be good google search results.

On Sep 12, 4:12 pm, aaronblohowiak <aaron.blohow...@gmail.com> wrote:
> These are the basic facts:
>
> DNS is a service that translates a name to an IP address.
> Node runs on a computer that has at least one IP address.
> Node can open 1 or more ports on that IP address (for instance, port
> 80 or port 3000.)
> Only one application can answer requests for a given IP address / port
> combination.
> Apache/nginx can accept requests on an IP/port combination and
> dispatch them to other applications to handle (called reverse
> proxying.)
>
> Here's the long explanation:
>
> If you have a domain currently pointing to the same IP address as the
> IP that node binds to, then you can access it using that domain.
>
> For instance, lets say you have a computer (server1) and it has the ip
> address 4.2.2.1. On server1 you currently have apache bound to port 80
> on 4.2.2.1.  This means that any request coming in to that IP address

> will be handled by apache.  So, if you point your browser tohttp://4.2.2.1:80
> (which is the default http port, so this is the same thing ashttp://4.2.2.1/)

>
> If you start node on the same computer and tell it to listen to port

> 3000 on the ip 4.2.2.1, then if you point your browser tohttp://4.2.2.1:3000

> then it will be handled by node.
>
> Let's say you have a domain name, omgwtfbbq.com. When you register the
> domain, you specify what computer is the DNS server for that domain
> (frequently, you will use the same company as you used to register the
> domain, but not always.)  At the DNS administration screen, you should
> have the ability to add records.  For now, we'll just talk about "A"
> records.  an "A" record is a lookup table from a name to an IP
> (simplified, but this is mostly true.. there are extensions that will
> only confuse things and you shouldnt need them.)  If you have a DNS
> entry that points omgwtfbbq.com to 4.2.2.1 and pants.omgwtfbbq.com to
> 4.2.2.1, then both names will point to the same computer.  It is
> common to use a wildcard ( *.omgwtfbbq.com ) to say that all
> subdomains should point to the same address as the primary.
>

> So, when you put inhttp://pants.omgwtfbbq.comin your browser, your

> browser goes, sees who the DNS server is for that name, then goes and
> asks the DNS server for that name what the IP address is for it.  in
> this case, it will "resolve" to 4.2.2.1.  At this point, it is just

> like you had typedhttp://4.2.2.1in the browser, *except* that the

> browser will send the name of the requested domain along with its
> normal communication to the server.
>

> Remember that the default port is port 80.  So, if you havehttp://pants.omgwtfbbq.comandhttp://omgwtfbbq.compointed to the

> ...
>
> read more »

[mscdex]

On Sep 12, 6:45 pm, Mark Nutter <marknut...@gmail.com> wrote:
> Node can run behind a reverse proxy like these, but doing so will kill the
> support for websockets (kind of destroying one of the main reasons for
> using node).
>
> So in order to get the full benefit of Node, I need to contact
> slicehost and ask for another IP which I dedicated directly to my node
> app. Am I on the right track?

You don't have to have a separate IP, you can just open up another
port on the same IP that node listens on. But yes, as of this writing,
if you want WebSocket support, you can't have anything in front of
node. Hopefully this will change sooner than later, as soon as SSL
support in node gets to be more usable than it is now. Only then will
we begin to see node-based reverse proxies worthy of replacing the
likes of haproxy (with the added ability to handle WebSocket
connections).

[Tiago Paiva]

Conclusion: if you want to use websockets, you have to use node as a
server alone and not nginx or apache unless your webpage links contain
the port (dont remember seeing this a lot). Right?

Thanks
Tiago Paiva

Sent from my iPhone

> --
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.

> To post to this group, send email to nod...@googlegroups.com.

> To unsubscribe from this group, send email to nodejs+un...@googlegroups.com

[mscdex]

On Sep 12, 8:08 pm, Tiago Paiva <pix...@gmail.com> wrote:
> Conclusion:  if you want to use websockets, you have to use node as a  
> server alone and not nginx or apache unless your webpage links contain  
> the port (dont remember seeing this a lot). Right?

For now, you have to run node on a separate port by itself for
WebSocket support. You can still use nginx/apache/what have you to
host the client code of course, which would point to the port node is
listening on for incoming WebSocket or whatever types of connections
you want.

As discussed in another thread, it's not that *all* WebSocket
connections won't work with a reverse proxy like haproxy, it's just
that latest modern browsers use draft76 or newer (such as Chrome 6+,
Firefox 4, and one of the more popular Flash-based WebSocket emulation
layers at http://github.com/gimite/web-socket-js) which incorporate
HTTP breakage by design. Some versions of browsers that use draft75,
which is HTTP compliant, do in fact work fine with haproxy (such as
Chrome 5 and Safari 5).

[Terry Riegel]

Mark,

Do you have node installed on your server? Do you have ssh access?

I would definitely recommend setting up the sample server (the one on the nodejs website). Do you need help with the actual ssh part and the commands to type?

I an just trying to get a feel for where you are so I can give some more concrete advise.

Terry Riegel

> To post to this group, send email to nod...@googlegroups.com.
> To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.

[Mark Nutter]

> You can still use nginx/apache/what have you to
> host the client code of course, which would point to the port node is
> listening on for incoming WebSocket or whatever types of connections
> you want.

Wait, so you can have, say, apache pointing traffic to a rails app, or
static webpage, or what have you, and you could open a websocket on
that app and have it point at a port that's listening to a running
node.js server, and you could be pushing to the client that way?
Meaning, I could have some background process running in the
background, pushing stuff through a running node.js server straight to
the client of a person connected via websockets on one of my rails
apps (I basically want to duplicate the functionality of
pusherapp.com)? Cuz that would be awesome. If so, how would one
accomplish this?

On Sep 12, 7:24 pm, mscdex <msc...@gmail.com> wrote:
> On Sep 12, 8:08 pm, Tiago Paiva <pix...@gmail.com> wrote:
>
> > Conclusion:  if you want to use websockets, you have to use node as a  
> > server alone and not nginx or apache unless your webpage links contain  
> > the port (dont remember seeing this a lot). Right?
>
> For now, you have to run node on a separate port by itself for
> WebSocket support. You can still use nginx/apache/what have you to
> host the client code of course, which would point to the port node is
> listening on for incoming WebSocket or whatever types of connections
> you want.
>
> As discussed in another thread, it's not that *all* WebSocket
> connections won't work with a reverse proxy like haproxy, it's just
> that latest modern browsers use draft76 or newer (such as Chrome 6+,
> Firefox 4, and one of the more popular Flash-based WebSocket emulation

> layers athttp://github.com/gimite/web-socket-js) which incorporate

[mscdex]

On Sep 12, 9:26 pm, Mark Nutter <marknut...@gmail.com> wrote:
> Wait, so you can have, say, apache pointing traffic to a rails app, or
> static webpage, or what have you, and you could open a websocket on
> that app and have it point at a port that's listening to a  running
> node.js server, and you could be pushing to the client that way?
> Meaning, I could have some background process running in the
> background, pushing stuff through a running node.js server straight to
> the client of a person connected via websockets on one of my rails
> apps (I basically want to duplicate the functionality of
> pusherapp.com)?  Cuz that would be awesome.  If so, how would one
> accomplish this?

What I meant was the WebSocket connection would be direct from the
client's browser to the node server, but the code to make this
connection could be served by Apache.

[Mark Nutter]

Terry,

I'm on a slicehost account with full ssh rights, basically a blank
slice, they walk you through how to get everything setup, from apache
to passenger to mysql to postfix, etc. I can get a new rails app setup
on a new domain, and everything associated with that. But because
passenger really automated a lot of the web server side of things I've
never really been forced to sit down and learn about the underpinnings
of how web servers work - I just focus on building rails apps.

So yeah, I have full access and at least know my way around enough to
be dangerous. I actually got a node sample app up and running (a chat
client), and pointed to it with apache, but the websocket didn't look
like it was connecting (probably because of it being behind apache).
The thing that was really throwing me with getting a sample node.js
app was that it didn't seem like adding a virtual host to apache was
the right way to go about it (which is how I get a new rails app
online). I want to know both how to host node.js apps and I also want
to know how to connect to node.js servers from rails apps (duplicating
the functionality I can get with pusherapp.com). I have the sample
node.js apps running on my local machine (OS X), but I want to get
them online so I know how to put other toy apps I create as I learn
node.js. I hope that gives you an idea of where I'm at expertise-
wise.

Thanks!

On Sep 12, 8:22 pm, Terry Riegel <rie...@clearimageonline.com> wrote:
> Mark,
>
> Do you have node installed on your server? Do you have ssh access?
>
> I would definitely recommend setting up the sample server (the one on the nodejs website). Do you need help with the actual ssh part and the commands to type?
>
> I an just trying to get a feel for where you are so I can give some more concrete advise.
>
> Terry Riegel
>

> >> So, when you put inhttp://pants.omgwtfbbq.cominyour browser, your

> >> browser goes, sees who the DNS server is for that name, then goes and
> >> asks the DNS server for that name what the IP address is for it.  in
> >> this case, it will "resolve" to 4.2.2.1.  At this point, it is just

> >> like you had typedhttp://4.2.2.1inthe browser, *except* that the

> >> browser will send the name of the requested domain along with its
> >> normal communication to the server.
>

> >> Remember that the default port is port 80.  So, if you havehttp://pants.omgwtfbbq.comandhttp://omgwtfbbq.compointedto the

> ...
>
> read more »

[Mark Nutter]

> What I meant was the WebSocket connection would be direct from the
> client's browser to the node server, but the code to make this
> connection could be served by Apache.

I tried this. I threw a node.js chat demo on my server, pointed
apache at the html file that came with the demo, and started the
node. The page resolved, and I could visit the chat room, but it just
said "node disconnected" every time.

[aaronblohowiak]

> So what you're saying is, nginx and apache are the things giving the
> browser the proper website based on the domain name, even though all
> the different domains are really sitting on one IP address.  Node can
> run behind a reverse proxy like these, but doing so will kill the
> support for websockets (kind of destroying one of the main reasons for
> using node).

If you want to use the same port, then yes, that is what I am saying.
You only need the port to be 80 if you want node to respond as the
provider for the default. You can always use a port other than 80.
It just means that urls need to contain the ":". If you have a rails/
php/django app that uses node just for websockets, then you can have
your websocket server on a different port and it will all be gravy (as
long as your websocket configuration is set up to handle this.) This
may not play well with other streaming techniques because of origin
policies.. perhaps someone else could pitch in here.

This will get better when we can do websockets over SSL because it
should let us start using reverse proxies (i am a little fuzzy on
this, but that is what it sounds like here:
http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-76#section-1.8
)

> So in order to get the full benefit of Node, I need to contact
> slicehost and ask for another IP which I dedicated directly to my node
> app. Am I on the right track?

you can do it this way, yes. or just get another slice =)

> Again, thanks so much, it can be difficult to break into this stuff as
> a beginner sometimes, especially since the more entry-level the
> question the less likely there are to be good google search results.

Apache SUCKS for having very many long-standing connections open,
nginx is somewhat better.

[aaronblohowiak]

You would have to look at the javascript source to know that the
websocket is on a different port.

[aaronblohowiak]

Yes.

[Gerad Suyderhoud]

Here's one way to deploy node.js with web sockets behind an apache
virtual host.

http://fortnightlabs.posterous.com/deploying-with-nodejs

[mscdex]

On Sep 13, 1:23 am, Gerad Suyderhoud <ger...@gmail.com> wrote:
> Here's one way to deploy node.js with web sockets behind an apache
> virtual host.
>
> http://fortnightlabs.posterous.com/deploying-with-nodejs

That's fine as long as you're either doing development work or you
don't expect your WebSocket setup to scale very high. Going through
Apache will still spin up a thread for the incoming WebSocket
connection.

[Mark Nutter]

> Apache will still spin up a thread for the incoming WebSocket
> connection.

Doesn't that kind of defeat the purpose of WebSockets?

[Timothy Caswell]

I come from the ruby world and understand passenger and friends. Also I have experimented with several methods of deploying node apps.

I'll tell you deploying node apps is the same as deploying ruby apps (except there is nothing like passenger for node). Ruby apps can serve themselves using thin, mongrel, webrick, etc... Node apps can serve themselves using node! The difference is that node is much faster and more capable. You can serve static assets with node directly if you want. It's fast enough. Don't do that with any of the ruby servers except for local dev servers.

Like others have said, the only reason to put node behind a reverse proxy is to support virtual hosting. That's where a front program takes the http request to an ip address and port, peeks at the "Host" http header and forwards/proxies the request to another server on another port of a unix socket. That's exactly what passenger does for you, and in the ruby world is the only sane way to deploy production apps.

Now things get tricky if you want to support new technologies like websockets or take advantage of node's super high efficiency with high concurrency. Then if you use a reverse proxy, you're running through two servers and are limited by the smallest subset of their two capabilities. Nginx and Apache don't handle high currency as well as node (especially apache) And most http reverse proxies don't support the newest websocket protocol since it's not really http.

My favorite setup, and I recommend it for any production apps, is to get a unique IP address per node app. Then you can run your node apps directly on port 80 and skip all the reverse proxy mess and still have different domains on the same box.

I hope this clears things up a little.

[Peter Griess]

On Mon, Sep 13, 2010 at 10:29 AM, Timothy Caswell <t...@creationix.com> wrote:

Like others have said, the only reason to put node behind a reverse proxy is to support virtual hosting.

At the risk of being being pedantic, there are several other reasons why you would want a reverse HTTP proxy fronting node:

• Load balancing between different hosts
• Hardware SSL acceleration
• Better HTTP caching implementations, and not just for static files (yes, you can get Node to do this with some work, but there are a wide variety of HTTP proxy caches that perform extremely well off the shelf)
• Not wanting to put Node's HTTP stack on the public internet (e.g. if it hasn't passed your company's security/risk process)

And, of course, just to be difficult, routing based on vhost can be done within Node as well ;)

    http://blog.std.in/2010/07/22/nodejs-more-intelligent-routing/

Peter 

--

@pgriess / http://blog.std.in

[mscdex]

On Sep 13, 7:04 am, Mark Nutter <marknut...@gmail.com> wrote:
> > Apache will still spin up a thread for the incoming WebSocket
> > connection.
>
> Doesn't that kind of defeat the purpose of WebSockets?

It's not so much defeating the purpose of WebSockets as it is
defeating the purpose of having an evented and high performance
framework like node.

[Timothy Caswell]

Fair enough, I was over simplifying the problem.  Peter is more correct.

[MilesTogoe]

On 09/13/2010 08:29 AM, Timothy Caswell wrote:
> I come from the ruby world and understand passenger and friends. Also I have experimented with several methods of deploying node apps.
>
> I'll tell you deploying node apps is the same as deploying ruby apps (except there is nothing like passenger for node). Ruby apps can serve themselves using thin, mongrel, webrick, etc... Node apps can serve themselves using node! The difference is that node is much faster and more capable. You can serve static assets with node directly if you want. It's fast enough. Don't do that with any of the ruby servers except for local dev servers.
>
> Like others have said, the only reason to put node behind a reverse proxy is to support virtual hosting. That's where a front program takes the http request to an ip address and port, peeks at the "Host" http header and forwards/proxies the request to another server on another port of a unix socket. That's exactly what passenger does for you, and in the ruby world is the only sane way to deploy production apps.

Thanks Tim for some explanation. Now, if the virtual hosting is only
for different node apps: then is it still advisable to use nginx ? or
just use multiple node instances with different ports for each app ? Is
that possible ? Any examples ?

If just running Node (no nginx) is it still advisable to combine with
something like Monit to keep it running ?

Finally, what is the advantage of running with web sockets instead of
http.server ? If we are only using Node should we really be using web
sockets (I don't think we need ssl at this point). If so are there any
examples using sockets ?

[Timothy Caswell]

I'd only use websockets if you prefer the message model or really need the super low latency.  Websockets are usually used in conjunction with http (to serve static resources).

Note that Peter did correct me.  It's possible to do virtual hosting using a parent node program instead of nginx or apache, and there are other purposes of using a proxy than virtual hosts.

If you run each node server on it's own port, then it's the same as each having it's own unique IP (Expect the browser needs to specify the port to get to it.  DNS only aliases IP addresses, not ports)

There are several examples of programs out there.  A recent one I built it http://github.com/creationix/adventure.  It uses connect for http and socket.io for websockets.  I have it hosted at creationix.no.de which is a unique ip, so no reverse proxy is needed.

[Kenneth Grome]

Wouldn't it be easier to just specify a different port for node?

I know that we seldom see ports in URLs these days but I don't think
it's a big deal to use them. A decade ago we seldom saw 3rd level
domains in URLs either (except for www) and now everyone uses 3rd
level domains and even 4th level domains.

Sincerely,
Kenneth Grome

[Guillermo Rauch]

Don't forget that using a non-80 port will break all the proxies that only allow "web traffic" (eg: corporate proxies).

--
Guillermo Rauch
http://devthought.com

[Dean Landolt]

On Mon, Sep 13, 2010 at 6:33 PM, Guillermo Rauch <rau...@gmail.com> wrote:

Don't forget that using a non-80 port will break all the proxies that only allow "web traffic" (eg: corporate proxies).

Another reason by draft76 is doomed to fail.

[Kenneth Grome]

This is a non-issue for me because my app is targeted to individuals
not corporate users. Be that as it may, what about SSL port 443?

Sincerely,
Kenneth Grome

[Dean Landolt]

On Mon, Sep 13, 2010 at 6:42 PM, Kenneth Grome <keng...@gmail.com> wrote:

This is a non-issue for me because my app is targeted to individuals
not corporate users.  Be that as it may, what about SSL port 443?

I'm an individual. I don't even work for a big company but I'm usually VPN'd in on my home box and all my traffic is routed through my company's proxies (yes, I know how bad of an idea this is but I'm not all that worried). I know my case isn't that exceptional.

[Jay Adkisson]

To me, urls, especially the domain name, are pure UI.  You want people to remember where to find you.  Subdomains can be intelligently designed to make semantic sense, but port numbers cannot.

--Jay

--

[Stephen Belanger]

No one should ever see the websocket port though. It's only viewable in the source.

[Jay Adkisson]

Very good point.  Combined with the fact that a node HTTP server can listen on multiple interfaces, that's a pretty nice setup.  Although I'm still holding my breath for the nginx folks to get WebSockets figured out.

--Jay

[MilesTogoe]

On 09/13/2010 05:17 PM, Stephen Belanger wrote:

No one should ever see the websocket port though. It's only viewable in the source.

yeah, I was trying to figure out what was being talked about

with virtual hosting wouldn't it be something like:

domain1.com  =>                                             => node instance port 8020
                           server (w/ virtual host code)
domain2.com =>                                              => node instance port 8040

so the only place the ports are specified are on the server


anyway trying to make some sense of typical server setups for a good write up on the node wiki

[Mark Nutter]

Thanks to everyone who replied here, things are very cleared up for
me. I'm very excited to get something up and running!

On Sep 13, 10:14 pm, MilesTogoe <miles.to...@gmail.com> wrote:
>   On 09/13/2010 05:17 PM, Stephen Belanger wrote:
>
> > No one should ever see the websocket port though. It's only viewable
> > in the source.
>
> yeah, I was trying to figure out what was being talked about
>
> with virtual hosting wouldn't it be something like:
>
> domain1.com  =>                                             => node
> instance port 8020
>                             server (w/ virtual host code)
> domain2.com =>                                              => node
> instance port 8040
>
> so the only place the ports are specified are on the server
>
> anyway trying to make some sense of typical server setups for a good
> write up on the node wiki
>
>
>
>
>

> > On 2010-09-13, at 4:45 PM, Jay Adkisson <j4yf...@gmail.com

> > <mailto:j4yf...@gmail.com>> wrote:
>
> >> To me, urls, especially the domain name, are pure UI.  You want
> >> people to remember where to find you.  Subdomains can be
> >> intelligently designed to make semantic sense, but port numbers cannot.
>
> >> --Jay
>

> >> On Mon, Sep 13, 2010 at 4:19 PM, Dean Landolt <d...@deanlandolt.com
> >> <mailto:d...@deanlandolt.com>> wrote:
>
> >>     On Mon, Sep 13, 2010 at 6:42 PM, Kenneth Grome

> >>     <kengr...@gmail.com <mailto:kengr...@gmail.com>> wrote:
>
> >>         This is a non-issue for me because my app is targeted to
> >>         individuals
> >>         not corporate users.  Be that as it may, what about SSL port 443?
>
> >>     I'm an individual. I don't even work for a big company but I'm
> >>     usually VPN'd in on my home box and all my traffic is routed
> >>     through my company's proxies (yes, I know how bad of an idea this

> >>     is but I'm not all that worried). I know my case isn't /that/

> >>     exceptional.
> >>     --
> >>     You received this message because you are subscribed to the
> >>     Google Groups "nodejs" group.
> >>     To post to this group, send email to nod...@googlegroups.com

> >>     <mailto:nod...@googlegroups.com>.

> >>     To unsubscribe from this group, send email to
> >>     nodejs+un...@googlegroups.com

> >>     <mailto:nodejs+un...@googlegroups.com>.

> >>     For more options, visit this group at
> >>    http://groups.google.com/group/nodejs?hl=en.
>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "nodejs" group.
> >> To post to this group, send email to nod...@googlegroups.com

> >> <mailto:nod...@googlegroups.com>.

> >> To unsubscribe from this group, send email to
> >> nodejs+un...@googlegroups.com

> >> <mailto:nodejs+un...@googlegroups.com>.

[Tiago Paiva]

Tell us what you end up doing.

[Kenneth Grome]

In my case no one will access my node server unless they first visit my
lighttpd-served site then click on a link. That link can have my node
port in it, and it can even be an ip address rather than a domain name
and I couldn't care less -- because I'm not trying to serve my main
site from node. I'm only trying to serve a special feature, one that
node should perform better at than a traditional web server.

My visitors will remember my domain name for sure, but they are never
expected to access my node site without first visiting a page on my
main site.

Sincerely,
Kenneth Grome

[Mark Nutter]

Interesting approach!

[Mark Nutter]

> Tell us what you end up doing.

will do!

> > > >>     nodejs+un...@googlegroups.com<nodejs%2Bunsu...@googlegroups.com>
> > > >>     <mailto:nodejs+un...@googlegroups.com<nodejs%2Bunsubscribe@googlegrou ps.com>

> > >.
> > > >>     For more options, visit this group at
> > > >>    http://groups.google.com/group/nodejs?hl=en.
>
> > > >> --
> > > >> You received this message because you are subscribed to the Google
> > > >> Groups "nodejs" group.
> > > >> To post to this group, send email to nod...@googlegroups.com
> > > >> <mailto:nod...@googlegroups.com>.
> > > >> To unsubscribe from this group, send email to

> > > >> nodejs+un...@googlegroups.com<nodejs%2Bunsu...@googlegroups.com>
> > > >> <mailto:nodejs+un...@googlegroups.com<nodejs%2Bunsubscribe@googlegrou ps.com>

> > >.
> > > >> For more options, visit this group at
> > > >>http://groups.google.com/group/nodejs?hl=en.
> > > > --
> > > > You received this message because you are subscribed to the Google
> > > > Groups "nodejs" group.
> > > > To post to this group, send email to nod...@googlegroups.com.
> > > > To unsubscribe from this group, send email to

> > > > nodejs+un...@googlegroups.com<nodejs%2Bunsu...@googlegroups.com>

> > .
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/nodejs?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "nodejs" group.
> > To post to this group, send email to nod...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > nodejs+un...@googlegroups.com<nodejs%2Bunsu...@googlegroups.com>

[Nate]

Tim can you explain that last statement? Is the reason you can still
have different domains on the same box because each app has a unique
IP? I don't quite understand how you can still have different domains
on the same box.

[Timothy Caswell]

If you have multiple IP addresses, then you serve app A on one IP (as the host parameter to node's listen() call) and serve app B on another IP. Then in your DNS point domain A to the first IP and domain B to the second IP.

[Tiago Paiva]

With that setup you cant use EC2. unless you have more than one
instance.

Tiago Paiva

Sent from my iPhone

No dia 2010/09/15, às 19:00, Timothy Caswell <t...@creationix.com>
escreveu:

[Matt Ranney]

I didn't realize how widespread this was until recently.  Apparently many hotel, cafe, airport, and other more public WiFi networks do not allow outbound connections on ports other than 80 and 443.  So yeah, use port 80 somehow, if you can.

[Jeremy Johnstone]

Hey Tim,

No offense, but this approach is very wasteful in IP addresses. It's part of the reason we are less than one year away from running out of IPv4 IP addresses.

I apologize as I missed earlier context, but why would one not inspect the Host: header and use it to switch between different domains without having to muck with ports or excessive IP address usage?

-Jeremy

[Timothy Caswell]

Yes, it is wasteful, but given the lack of good reverse proxies, it's the most robust solution. (maybe we should just run out and use ipv6, but that's another debate)  vhosting is a great solution if you app can handle something being in front directing the traffic based on HTTP headers.  You can easily do this in-process with connect's vhost middleware (both domains would be in the same node process(es)) or use a reverse proxy that understand enough http to forward on without loosing the benefits of node.

[pixel67]

I'm trying to figure this out as well, I have a VPS that I set up for node hosting, I'm using NGINX.

I found this article just now while searching about `configuring server to host node application`

http://dailyjs.com/2010/03/15/hosting-nodejs-apps/

hope it helps

On Sunday, September 12, 2010 10:29:00 AM UTC-4, Mark Nutter wrote:

I'm just getting into node.js and I haven't been able to find any
guides on how to actually setup a node.js server on a linux server, in
my case a slicehost slice.  I'm no sysadmin expert, I just used
passenger/apache and the guides on Slicehost to get my rails apps up
and running.  So how would I get an example node.js app running and
available on a subdomain, accessible from the web?  Is this done in
apache?  Or are there other ways to get subdomains or domains to
listen to port 8000.  I just want to get an example up and running
somewhere other than my local machine.   Big time noob  here, some
guidance would be very appreciated.

[Dylan Hassinger]

This was challenging for me too, the way I learned to do it was:

• install Node and get your app running at the ip:port address
  
• use node-http-proxy to set route your subdomain to this port
  
• launch both the app and http-proxy using forever, so they run in the background

I made a loader for http-proxy that lets you store your settings in a config file:

https://github.com/dylanized/http-proxy-loader

Feel free to email me if you need a hand. There may be a better way to do this - in fact, I hope there is! :)

- dylan in santiago

--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines

You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com

To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com

For more options, visit this group at

http://groups.google.com/group/nodejs?hl=en?hl=en
 
---

You received this message because you are subscribed to the Google Groups "nodejs" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Clay Simmons]

I'm surprised no one has mentioned haproxy yet. In my production setup, I use haproxy in front of Node and Apache. It also supports websocket connections. I'm running an app that has an admin console that runs on a typical LAMP stack (except the M in my scenario is MongoDB), but the client-facing app is an NodeJS app with a real-time component that broadcasts data via a websockets connection. A little more detail:

In this setup the DNS for the following domains all point to the same IP address:

admin.appdomain.com

clientapp.appdomain.com

haproxy is the application listening on port 80. Apache is listening on port 3000 and node is listening on port 8000. The websockets IO server is listening on port 4000. I have 3 ACLs setup in haproxy to forward requests to the appropriate backend based on various conditions. Here's the pseudo-config of what's implemented in the haproxy config:

If the host address of the request ends in admin.appdomain.com, forward to Apache.

If path of the requested file begins in /io01/, forward to the websockets node backend.

All other requests are forwarded to the node client app on port 8000.

Note that in this scenario, the websockets requests and the client app requests are on the same domain, so I don't run into CORS issues. haproxy can route requests based on request paths, not just domains.

You can also put nginx in between haproxy and your node app in this scenario if you want nginx to handle serving static files. Another nice thing about haproxy is that if I needed to add more backends (more apache servers, more websockets servers, more node servers) and load-balance between them, I can do that fairly easily. It will also perform health checks on the backends and stop forwarding to them if they are down or unresponsive.

There are a ton of different ways to use haproxy, but in this scenario, it's kind of an intelligent traffic cop telling requests where to go to get served. It's never been the problem of a single failure either.

P.S. - I love haproxy, okay?