Tuesday, October 12, 2010

JSON-centric architecture

In my last post I mentioned that I'm now working at a startup.  I was one of the first employees, so I get to help set a lot of the technical direction.  I don't claim to be a genius, but I do like that part so I take the time to research what's out there.  We've been developing on this stack for just over 4 months and so far, so good.  We don't have a production environment with users yet, so it's too early to claim victory.  But we haven't come across any concerns yet, and everybody feels really productive.

I won't bore you with the things that we investigated but dismissed.  What's important is what made the cut and how we're putting things together.  Here's the highlevel view:



The main component in our architecture is Grails.  We love the fact that it's based on the JVM (we're all experienced Java programmers), but it doesn't carry the weight of the traditional Java EE world.  The fact that it's backed by SpringSource was a big factor for us.  We weren't comfortable with a platform/framework that didn't have significant support from the community or a real company.  SpringSource is now owed by VMWare so we know they're not going away any time soon.  And SpringSource is all about Java, so we feel confident that they'll continue to invest in Grails.  The quality of the plugins developed by SpringSource has been fantastic.  Can't say it enough...I love Grails.

Another decision we had to make was how to expose our services to various client devices (browsers, smart phones, other applications, etc.).  We quickly settled on JSON over REST.  We started out being "REST-like", just exposing HTTP GETs.  But we then realized (thanks MikeD!) that we should really follow the REST protocol.  I'm so glad we did, because it opened up the possibility to plugin standard components that support REST (we're using Jersey).  It also simplified our discussions about "what should our URLs look like?".  If you follow the REST protocol, most of those questions are answered for you.

JSON was an easy choice over XML simply because JSON, well.....JSON is simple, and XML is verbose.  Sure, XML has great tool support.  But JSON is gaining momentum in the community and is so easy to create, store, parse, debug, etc.  And the integration between Grails maps and JSON documents is dead simple.  Simple == good.

The next big choice was for the database manager.  We chose MongoDB.  I'll admit that we're taking a flyer on this one, and I'm a tad nervous about it.  One of the main reasons we chose Mongo is because it is a document-based datastore.  JSON documents, in fact.  Given that we're using JSON documents on the front-end (exposed through the RESTful services), and Grails as the app server, having a JSON-document datastore allows us to deal with JSON documents everywhere.  Again...dead simple.  The idea of transforming data from one format to another is almost non-existant in our architecture.

Mongo is not without risks and trade-offs.  Mongo doesn't support transactions, so we may have to get creative with our processing to ensure we don't lose updates.  We've already made some decisions to work around it, but the impact has been minor.  And Mongo isn't supported by a big name player.  10gen is doing a great job with it so far, and I hope they continue.

There are more components to discuss but I've rambled on long enough for now....