Michael, this is a really helpful response. Thanks. I think it's important to realize that yes, node certainly *can* do pretty much all the work that you would do with PHP. But, that doesn't mean someone has the time or inclination to rewrite some big app that's *already* in PHP. There may be benefits to doing so, but it's certainly also got a lot of cost.
In the real world, we often don't have the luxury of starting over. On Tue, May 1, 2012 at 3:14 PM, Michael Wulf <katow...@gmail.com> wrote: > 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, zeromq, nowjs, 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!). 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 -- 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
