 |
 |
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