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.
