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! > -- 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 nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
