On Tue, May 8, 2012 at 10:17 AM, Ethan Gruber <[log in to unmask]> wrote:

> Thanks.  I have been working on a system that allows editing of RDF in web
> forms, creating linked data connections in the background, publishing to
> eXist and Solr for dissemination, and will eventually integrate operation
> with an RDF triplestore/SPARQL, all with Tomcat apps.  I'm not sure it is
> possible to create, manage, and deliver our content with node.js, but I was
> told by the project manager that Apache, Java, and Tomcat were "showing
> signs of age."  I'm not so sure about this considering the prevalence of
> Tomcat apps both in libraries and industry.  I happen to be very fond of
> Solr, and it seems very risky to start over in node.js, especially since I
> can't be certain the end product will succeed.  I prefer to err on the side
> of stability.
>
> If anyone has other thoughts about the future of Tomcat applications in the
> library, or more broadly cultural heritage informatics, feel free to jump
> in.  Our data is exclusively XML, so LAMP/Rails aren't really options.
>
>
We've used node.js (but not Express, their web app framework) to build our
own experimental AJAX framework (http://cloudbrowser.cs.vt.edu/ ). We also
have extensive experience with Tomcat-based systems.

Given that wide, and increasing use of node.js, I'm optimistic that it
should be stable and reliable enough for your needs; let me emphasize three
points you may want to consider.

a) You're programming in JavaScript/CoffeeScript, which is a higher-level
language than Java. My students are vastly more productive than in Java.
The use of CoffeeScript and require still allows for maintainable code.

b) node.js is a single-threaded environment. Reduced potential for some
race conditions, but requires an asynchronous programming style. If you've
done client-side AJAX, you'll find it familiar; otherwise, you need to
adapt. New potential for race conditions.

c) Scalability. Each node.js instance runs on a single core; modules exist
for clustering on a single machine. I don't know/don't believe session
state replication is as well supported as for Tomcat. On the other hand,
Tomcat can be a setup nightmare (in my experience).

d) Supporting libraries. We've found the surrounding infrastructure
excellent. A large community is developing for it http://search.npmjs.org/ .
The cool thing is that many client-side libraries work or are easily ported
(e.g. moment.js).

e) Doing XML in JavaScript. Though JavaScript as a language is intended to
be embedded in XML documents, processing XML in JavaScript can be almost as
awkward as in Java. JSON is clearly preferred and integrates very naturally.

 - Godmar