Moving to a New Stack - AJAX, REST & NoSQL

Question

All, I'm beginning to explore what frameworks (open source) and tools for building web applications. What should I select and learn for the following layers,

Layer 1 Client side JavaScript / AJAX library or framework that will invoke REST style services provided by layer- 2

Layer 2 Provides a framework to rapidly create REST style services out of existing applications and out of a NoSQL document oriented database provided by layer-3. I need this layer in cases where I need to expose REST style services out of my traditional apps and RDBMS.

Layer 3 Which NoSQL to use - CouchDB or MongoDB that would work well with layer-2?

Will I need a MVC framework like RoR or a web/component framework like Wicket? Am I missing anything?

I also need recommendations for which tooling/IDE (and associated plugins) for the development environment. Thanks in advance for your answers/thoughts.

Answer 1

The task you're trying to accomplish determines the technology you use.

Answer 2

If you're interested in the .NET platform, consider:

• RavenDB for the data layer.
• WCF Data Services for your REST services layer. Here's a guide to WCF Data Services with some great video tutorials.
• If you need a web front-end, consider ASP.NET MVC or plain HTML as you see fit. jQuery and AJAX modules are well suited in both.

Arguably, ASP.NET MVC IS a REST endpoint of sorts, so you could skip the WCF services.

All the above can be leveraged with free tools, including:

• Visual Studio Express
• Raven DB's HTML interface at http://localhost:8080/

Answer 3

We've had pretty decent luck using a Java stack:

1. For the presentation, we use jQuery and jQueryUI, with Freemarker for XHTML/CSS templating, including to invoke REST web services through various UIs.

2. Restlet (www.restlet.org) is a wonderfully rich framework for crafting REST web services in Java. We decided to use it on a major product after it was strongly recommended to us by the engineering director of a top 10 e-commerce site in the US. And everything he said about it was true.

3. Unless you know you're going to face a really large amount of write volume, you're probably best off using one of the tried and true SQL databases supporting ACID transactional guarantees. We used Oracle, then switched to PostgreSQL, using the MyBatis (formerly iBatis) SQL Mapper to shield our code from the details of the database. With the advent of 64-bit addresses and scads of inexpensive DRAM, plus SSDs, these old workhorses do scale quite high.

4. If you are anticipating very large amounts of writes, by all means consider a so-called "NoSQL" database. I heard very good things about Vertica from the top network ops folks at a major technology company last week. MongoDB and CouchDB both look interesting. Or you may be able to leverage persistent distributed cache technology like Redis or EhCache to offload a traditional database.