Having made something small work on OpenShift, I decided to take a look a CloudFoundry. I learned quickly that Cloud Foundry is not as Python-friendly as OpenShift. You can run Python applications on CloudFoundry using a 3rd-party extension, but this capability is not packaged in a very friendly manner, and there is not much documentation (or at least it is not easy to find). I was concerned that if I went down that path, I was going to have to learn much more detail about CloudFoundry and its workings than I would like. What CloudFoundry really likes to do is Java and Ruby. All of our application is fairly basic and trivial, but the part that is the least developed is the web UI server. I thought it might be interesting to develop a new web UI server using Ruby on Rails and deploy it on CloudFoundry.com (a site that hosts the software from CloudFoundry.org). This CloudFoundry web UI server can hopefully use the Python business logic server we have running at OpenShift, and we ought to also be able to continue to use the Python "dispatch and authentication server" at OpenShift. (See my previous post summarizing our OpenShift architecture if this is not making sense to you.)
Of course I know next to nothing about Ruby on Rails, so I did not know what I was getting into. Ruby on Rails is historically a framework to ease the implementation of two-tier web applications built on relational databases. It is made up of two basic parts 1) a large and complex framework that your application code extends 2) a set of generators that allow you generate application code from simple inputs, for example a description of your application entities and their fields. Ruby on Rails has a lot of function to help you handle validation, errors, schema migration and so on. It even has a test framework to help you build and execute automated unit tests, and a console/shell to help you interactively debug your application.
Since I did not want a relational back-end, I had to figure out how to get Rails to do the presentation part and leave the logic and data access to me. The good news is that it turned out that it was very simple to do this. The bad news is that - as is typical of complex frameworks - it was difficult and took a long time to figure out what the simple thing is that I needed to do. My first instinct was to try to look at an example of someone who had implemented an alternative back-end for Rails already - there are multiple drivers for MongoDB for example. It turns out those things are monumentally complex (why?) and after hurting my head for while trying to figure one out, I gave up that line of attack. My second approach was to try to prevent Rails from connecting to the relational database in the first place, so I could then take over. The problem with that approach is that it suppresses the generation of a number of files that - if you could see them - hold the keys to understanding how Rails interacts with your application code. I also wasted a fair bit of time on this attack. What finally worked was to let Rails generate the code for relational, learn from that how the application was stitched together, adjust the Rails dependency declarations to remove the dependency on relational, and then change the generated artifacts to not use the relational function. Now that I know what I need to change, I can revert to my second approach of not generating the relational dependency in the first place. It probably took me 3 days to figure all this out, and it reminded me why I hate frameworks so much. Now that I know what to do I'm hoping it only takes me another day or so to connect my Rails application to our OpenShift servers.