Best way to send data between php and Node - nodejs

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion Best way to send data between php and Node
Date: Tue, 1 May 2012 15:14:27 -0700 (PDT)
From: Michael Wulf <katow...@gmail.com>
To: nodejs@googlegroups.com
Message-ID: <26686965.913.1335910467584.JavaMail.geo-discussion-forums@vbbfr18>
In-Reply-To: <CAB=r2X-9Y2JM+X3429LpV=+mOdb06R=f9G-qSJpvMMxb1XOBFQ@mail.gmail.com>
References: <CAB=r2X-9Y2JM+X3429LpV=+mOdb06R=f9G-qSJpvMMxb1XOBFQ@mail.gmail.com>
Subject: Re: Best way to send data between php and Node
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_911_9023982.1335910467582"

------=_Part_911_9023982.1335910467582
Content-Type: multipart/alternative; 
	boundary="----=_Part_912_45509.1335910467582"

------=_Part_912_45509.1335910467582
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Alright, well let's throw out the choices with some sort of comparison. 

Since this is a topic of interest to me, I'll be the martyr and put my 
thoughts on the table first. Surely more apt heavyweights will offer some 
corrections (thanks in advance).

It seems to me the options are a message queue, a socket (TCP?), http 
requests, pipe at the command line (shell script?), send an email, or some 
sort of third party middleware solution (i.e. a great big, gigantic queue).

*A Message Queue*

An elegant approach, in my opinion. It would be critical to find a queue 
where your destination (queue workers) are on call, and not simply checking 
the queue on some time interval, if you want timely results (given your 
constraints):

Advantages: Plenty of queue systems available (Amazon SNS<http://aws.amazon.com/sqs/>, 
zeromq <http://www.zeromq.org/>, nowjs <http://nowjs.com/>, et al), allows 
processes to move at their own speed and resources, easy to scale. Easy to 
move off-server later without sizable changes.

Drawbacks: You need an implementation written in both PHP and Node to 
serve/handle requests (yay dNode <https://github.com/substack/dnode>!). 
Third party libs are almost required. May not adapt well to legacy code 
that isn't modular.

*A Socket*

Advantages: A straightforward approach. Just open a socket and keep it 
available so that two services can talk back and forth. Probably a day 
project to have up and running. For one-to-one connections, a great answer.

Drawbacks: Not easily scalable for many-to-one or many-to-many. Dropped 
connections and networking errors could be annoying in PHP unless you have 
a third party lib to assist. May not adapt well to legacy code that isn't 
modular.

*HTTP Requests*

Advantages: Dead simple. This is most likely how your legacy system already 
accepts requests if it's working with flash. Curl away! Easily scalable and 
modular, by adding servers behind a load balancer, assuming there's no SQL 
database involved.

Disadvantages: No pushes. Unless you're using an nginx or node http server, 
there is a sizable overhead to each request. Even with a single-threaded 
async server, this is probably more overhead than a queue or socket.

*A Pipe / Command Line Script*

Advantages: Assuming the destination is a script run on demand, there is a 
place to drop incoming data in order for it to be picked up, or that there 
is an access point in the destination process, this could be a very quick 
way to get things hooked up. Should adapt well to legacy code that is 
difficult to modify as the shell script can simply pretend to be flash 
sending in a request and move on. The "script" doing the piping could be 
JavaScript or PHP itself.

Disadvantages: No immediate answer from destination. Script needs to "call 
back" somehow. How are errors handled? Not well, probably.

And where does the data get stuffed? In a database? A file? It essentially 
becomes a queue, waiting for the running threads to check some data store, 
or the process must hold a socket open for the script to talk to, so 
perhaps this is no different than using a socket and overly complicated 
depending on the use case.

*Send an Email*

Advantages: A bit of an odd solution, and certainly a hack. But simple and 
straightforward to get up in a jiffy. The email is sent by one process, and 
either the mail server pipes the message to a script or the destination 
checks the account and processes.

Disadvantages: A bit convoluted, comes with all the baggage of 
email--connections, latency, spam/virus filters, poor standards--probably 
not applicable for anything more complex than a simple text message as the 
data is likely to get encoded/unencoded several times and be unreliably 
altered. But hey, it's easy.

*Middleware Solution*

Amazon SNS (mentioned above) and message queue services like this are 
essentially middleware of a sort. Here I mention it with the intention of a 
more traditional solution, such as third party software.

Advantages: this is essentially software that you will drop between the 
two. Can provide very robust, scalable, and complex connectivity. Can be 
used to filter/cache/simplify/adapt data between legacy systems.

Disadvantages: Difficult and time consuming to implement, usually costly. 
Way beyond the scope of your needs.



On Monday, April 30, 2012 10:06:50 AM UTC-7, sparky wrote:

> What's the best technique for sending small amounts of data back and forth 
> between node and php on the same server? Is dNode the best solution for 
> this? Or should I be looking at alternatives else?
>
> Thank you!
>

------=_Part_912_45509.1335910467582
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<div>Alright, well let's throw out the choices with some sort of comparison=
.&nbsp;</div><div><br></div><div>Since this is a topic of interest to me, I=
'll be the martyr and put my thoughts on the table first. Surely more apt h=
eavyweights will offer some corrections (thanks in advance).</div><div><br>=
</div>It seems to me the options are a message queue, a socket (TCP?), http=
 requests, pipe at the command line (shell script?), send an email, or some=
 sort of third party middleware solution (i.e. a great big, gigantic queue)=
.<div><br></div><div><div><b>A Message Queue</b><br></div><div><br></div><d=
iv>An elegant approach, in my opinion. It would be critical to find a queue=
 where your destination (queue workers) are on call, and not simply checkin=
g the queue on some time interval, if you want timely results (given your c=
onstraints):</div><div><br></div><div>Advantages: Plenty of queue systems a=
vailable (<a href=3D"http://aws.amazon.com/sqs/">Amazon SNS</a>, <a href=3D=
"http://www.zeromq.org/">zeromq</a>, <a href=3D"http://nowjs.com/">nowjs</a=
>, et al), allows processes to move at their own speed and resources, easy =
to scale. Easy to move off-server later without sizable changes.</div><div>=
<br></div><div>Drawbacks: You need an implementation written in both PHP an=
d Node to serve/handle requests (yay <a href=3D"https://github.com/substack=
/dnode">dNode</a>!). Third party libs are almost required. May not adapt we=
ll to legacy code that isn't modular.<br></div><div><br></div><div><b>A Soc=
ket</b></div><div><br></div><div>Advantages:&nbsp;A straightforward approac=
h. Just open a socket and keep it available so that two services can talk b=
ack and forth. Probably a day project to have up and running. For one-to-on=
e connections, a great answer.<br></div><div><br></div><div>Drawbacks: Not =
easily scalable for many-to-one or many-to-many. Dropped connections and ne=
tworking errors could be annoying in PHP unless you have a third party lib =
to assist. May not adapt well to legacy code that isn't modular.</div><div>=
<br></div><div><b>HTTP Requests</b></div><div><br></div><div>Advantages: De=
ad simple. This is most likely how your legacy system already accepts reque=
sts if it's working with flash. Curl away! Easily scalable and modular, by =
adding servers behind a load balancer, assuming there's no SQL database inv=
olved.</div><div><br></div><div>Disadvantages: No pushes. Unless you're usi=
ng an nginx or node http server, there is a sizable overhead to each reques=
t. Even with a single-threaded async server, this is probably more overhead=
 than a queue or socket.</div><div><br></div><div><b>A Pipe / Command Line =
Script</b></div><div><br></div><div>Advantages: Assuming the destination is=
 a script run on demand, there is a place to drop incoming data in order fo=
r it to be picked up, or that there is an access point in the destination p=
rocess, this could be a very quick way to get things hooked up. Should adap=
t well to legacy code that is difficult to modify as the shell script can s=
imply pretend to be flash sending in a request and move on. The "script" do=
ing the piping could be JavaScript or PHP itself.<br></div><div><br></div><=
div>Disadvantages: No immediate answer from destination. Script needs to "c=
all back" somehow. How are errors handled? Not well, probably.</div><div><b=
r></div><div>And where does the data get stuffed? In a database? A file? It=
 essentially becomes a queue, waiting for the running threads to check some=
 data store, or the process must hold a socket open for the script to talk =
to, so perhaps this is no different than using a socket and overly complica=
ted depending on the use case.</div><div><br></div><div><b>Send an Email</b=
><br></div><div><br></div><div>Advantages: A bit of an odd solution, and ce=
rtainly a hack. But simple and straightforward to get up in a jiffy. The em=
ail is sent by one process, and either the mail server pipes the message to=
 a script or the destination checks the account and processes.<br></div><di=
v><br></div><div>Disadvantages: A bit convoluted, comes with all the baggag=
e of email--connections, latency, spam/virus filters, poor standards--proba=
bly not applicable for anything more complex than a simple text message as =
the data is likely to get encoded/unencoded several times and be unreliably=
 altered. But hey, it's easy.</div><div><br></div><div><b>Middleware Soluti=
on</b></div><div><br></div><div>Amazon SNS (mentioned above) and message qu=
eue services like this are essentially middleware of a sort. Here I mention=
 it with the intention of a more traditional solution, such as third party =
software.</div><div><br></div><div>Advantages: this is essentially software=
 that you will drop between the two. Can provide very robust, scalable, and=
 complex connectivity. Can be used to filter/cache/simplify/adapt data betw=
een legacy systems.</div><div><br></div><div>Disadvantages: Difficult and t=
ime consuming to implement, usually costly. Way beyond the scope of your ne=
eds.</div><div><br></div><div><br></div><div><br></div><div>On Monday, Apri=
l 30, 2012 10:06:50 AM UTC-7, sparky wrote:<br></div><div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">What's the best technique for sending small amo=
unts of data back and forth between node and php on the same server? Is dNo=
de the best solution for this? Or should I be looking at alternatives else?=
<br><br>Thank you!<br>
</blockquote></div></div>
------=_Part_912_45509.1335910467582--

------=_Part_911_9023982.1335910467582--
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
