On Tue, May 31, 2011 at 11:39 AM, Sean Corfield <seancorfi...@gmail.com> wrote: > As of one hour ago, World Singles is now (finally) using Clojure in > production as part of our new internet dating platform. I'll send you > a write up for the success stories page once I've cleared it with > management (and after a suitable "burn-in" time on production to make > sure it really is a success story!).
Since a couple of people have asked off-list, I figured I'd provide a bit more detail about what we're doing with Clojure. First off, worldsingles.com is the corporate information site and there's no Clojure there. We have about fifty dating sites and over the last two years we've completely rebuilt the platform and we're migrating sites over one at a time (the new platform went live with one site last September). Currently live on the new platform are: * vietvibe.com * latinromantico.com * deafsinglesmeet.com * lovingbbw.com As you can probably tell, our niche is ethnic / specialty dating sites :) Most of the platform is CFML but we're using Clojure for: * environment control - auto-configuring the platform based on which server is hosting * logging - we're using log4j with a custom appender written in Clojure (that logs to a database) * ORM - member profiles (and several other objects in the system) are all persisted using a simple ORM based on clojure.java.jdbc The environment control piece determines all sorts of application settings, including database connections and so on. We had it in CFML originally but wanted a version we could reuse in Clojure and Scala to reduce duplication of configuration files and code. It's simple stuff: a map of default settings and a vector of maps (of settings) for each server group (as a regex on server name). The app settings var is a promise that is delivered once the application boots and looks up and merges settings based on the server name. The logging piece is very simple right now and uses the ORM to store matching data to a specific log table. We'll be expanding this to handle multiple types of data to multiple tables soon and then switching some of the logging to a noSQL data store (MongoDB most likely). The ORM is little more than a wrapper around clojure.java.jdbc but it handles naming strategies, key generation (for some tables), selecting which data source connection to use (we write to a master and read from slaves). The nature of OO in CFML means most of the work is currently in the CFML wrapper around this layer but we may well move some of that down into Clojure over time. Over time we expect to move more and more of our Model layer down into Clojure. Our Views are fairly complex and tied to CFML so I don't expect we'll shift the View-Controller portion although as we begin to expose APIs to the dating platform, we may well use Clojure for those endpoints. And I've started porting my lightweight convention-over-configuration MVC framework, FW/1, from CFML to Clojure as an experiment to see whether full end-to-end Clojure web development might be a fit for us - the currently available web frameworks in Clojure don't suit us. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
