That's a really complete answer! Thank you, that would helps us a lot :-)
Le mercredi 27 février 2013 18:25:43 UTC+1, jmar777 a écrit : > > I'm currently working on a project where we use both Node.js and Scala > extensively. Here are some requirements that would make me lean towards > Scala (specifically, Play): > > - Do you have a lot of CPU-bound activity? I would guess not based on > your description, but if so Scala may be a more natural fit. > - Do you have any operation that require buffering large amounts of > data in memory (vs. streaming from upstream to downstream)? > - Do you have any interoperability requirements with existing Java > code (not talking about service-based, but actually invoking JVM code > directly)? > > The above would all be defendable reasons to go with Scala. Scala is an > awesome language, Play is an impressive framework, Akka kicks butt, etc... > so I don't feel any need to bash that stack to promote Node.js. > > However, with that said, given a scenario in which both Node.js and > Scala/Play are viable solutions, I will go with Node.js 10/10 times. I > like it, I love it, I want more of it. We're using Node.js for an API > server that provides some similar "central routing" functionality like you > described: > > - We have multiple applications that use the API server for > authentication > - We have an application that ingresses ~2B data-points monthly, all > of which pass through (a single instance of) the API server. Granted, > that's only ~750 data-points/second, but it's run for months between > deployments without a single crash or showing any signs of a memory leak. > - The API server in turn exposes endpoints for a proprietary database > we've built for analyzing that data (which uses additional Node.js > components for its network routing and clustering). > - The API server provides all of our internal "dashboard" endpoints > for multiple applications > - etc.... > > The following are some of the reasons I dig Node for these types of > problems and think it could be a good fit for you: > > - Sub-second turnaround times between development and testing > - The above + the dynamic nature of JavaScript make Node.js awesome > for rapid application development, which is important for API components > that need to keep updating with evolving client and server needs > - Express (http://expressjs.com/) is awesome > - Someone will call be a hipster fanboi for saying it, but the > event-driven, non-blocking I/O model used by Node.js really is a good fit > for managing tons of connections in proxy-like situations > - The community > - The community > - The community > - Purely subjective, but I *enjoy* working with Node.js, which is > always a plus > - Shouldn't really have to be said, but it really is production ready > and battle hardened: > > https://github.com/joyent/node/wiki/Projects,-Applications,-and-Companies-Using-Node > - The verbiage right on the Node.js home page attests to the fact that > it's made for problems like you described: "Node.js is a platform built on > Chrome's JavaScript runtime *for easily building fast, scalable > network applications*." > > Anyway, hope that helps, and good luck convincing the boss :) > > On Tuesday, February 26, 2013 4:28:01 PM UTC-5, andreacode wrote: >> >> Hi everybody! >> >> I need some help on getting together as much information as possible on >> node.js (and its competitors), as we're going to start a quite project in >> our company, and we currently are in that phase in which you have to >> convince yourself and everybody else that this or that technology choice is >> the right one. >> >> The project is about a "Proxy API", as I often call it, a *central >> routing app* that should handle all the connections between our already >> existing applications. These are like 7 at the moment, but we want to >> separate some of them (especially the main one, a huge Ruby on Rails app >> that computes and displays quite everything behind it), so we want to >> create something very configurable, abstract, and prepared for future >> expansion of new apps. >> >> Obviously, the main point here is *availability*, as everything in the >> company (and perhaps, one day, our external clients as well) will >> constantly hit this API, and ask (and post) data, but almost nothing as to >> be computed in the API itself, we just pass the data to other apps, and >> maybe do some nice *caching* to not constantly hit other apps always for >> the same data. >> >> That said, we have to *convince the business counterpart* (we are a >> financial company) that node.js is well-suited for our use case, is ready >> for big numbers, and that (don't ask me why everyone in this damn sector >> thinks this) Java, or better the JVM, may not be the best way to go. >> Anyway, a nice comparison between the proposed languages would be very >> appreciated! >> >> Thank you in advance in any case! >> > -- -- 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 [email protected] To unsubscribe from this group, send email to [email protected] 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
