My usual reason for outright dismissing an app with a Rails front end centers on System.Transactions ability to continue a distributed transaction that was started in a web app process into a workflow. Since WF supports System.Transactions through compensating activities, I don’t want to give up the ability to issue a rollback on a transaction and have that carry through anything done with a workflow.
The problem with the last sentence is the word “anything”. It’s so damned vague that its meaningless from a tangible design perspective.
One of our customers could put literally anything into play when our application executes a workflow hook at significant state changes coded into the app. I can’t really guarantee that anything put into play in a workflow can support a rollback, or even if it would be sensible to make it support atomic transactions.
I literally can’t think of anything that we’re using workflow for that doesn’t require a more robust compensation mechanism than a System.Transactions rollback. In fact, the scenarios that I’m aware of the require compensation also require user intervention. This means that the compensation task flows also require user interfaces, which in turn means that compensation would probably be better served as entirely different use cases with different workflows.
I don’t have a lot of confidence that I need to or even should support using distributed transactions in customer-customizable workflows where that transaction is managed in an execution context that is intended to be synchronous and API-oriented rather the asynchronous and message-oriented.
Distributed transactions don’t seem like a good reason to dismiss Rails as a web front end.