I was curious when our client asked us to put our web flow definition files into the database. We used these files to define a basic navigation flows in our web application. To put it simply, our homemade framework was conceptually very similar to a Spring Web Flow. Such flow definition is a first class programming artifact and putting it into a database doesn’t make too much sense. You do not need to maintain application logic similar to some application business entity, since modifying it equals to deploying a new version of the application. What’s more, client is asking for a file to be saved in database in unstructured form, in a textual field.
Actually, storing the flow file in the database will provoke more than one problem. For example, preforming rollback becomes very unreliable since you need to synchronize the rest of the artifacts, for which on the other hand all you need to do is to deploy the old war, with the flow definition. If the database fails, the application will not be able to perform even the simplest navigation etc. Then there are security issues-you cannot sign the code anymore, probable performance issues etc. Even after being confronted with these issues, the client was still adamant that he needs this feature.
What was behind this request? As it happens, our client was working in a large corporation with strict, rigid policies in the IT department. Those policies defined a number of steps that had to be performed before new application could be put into production. And the process was terribly slow. Even the simplest change of to an application could take more than a month to perform. Our client, working in a certain department had to follow corporate policies, was unable to change them, but needed to move much faster.
So how placing the file in the database would help? Well, since application files would stay intact, he could simply update the database to change the application “no questions asked”. Of course, this means outwitting policies that were put in place in order to supposedly provide quality and security to IT operations. In this case, the client is at mercy of corporate policies and pushing the application logic into the database is the only way for him to do his job.
Another client has a similar story. A number of cryptic flags in the database are used to “configure” core business rules. No versioning or roll-back strategy in place, poor security (binaries are not signed), difficult to understand logic etc. Similar to the case above, procedures for getting the new version of base code into the production are quite complicated. There is a separate DB Admin Department in charge of performing the Q.C. of a proposed DB structure: in reality Q.C. consists of verifying that some cryptic prefixes are used when naming fields and tables. In this case, the team is much more empowered and could probably fix the deployment procedures. Unfortunately, the idea that the deployment pipeline could be automated and performed in such a short time to render the configurable logic mechanisms useless looks completely unrealistic.
Using configuration to store application logic has a number of downsides:
- Cryptic code difficult to interpret and maintain
- Poor security since configuration-code is generally not signed and access to modifying it is less restricted
- Generally no versioning or roll back mechanisms in place
- Probable performance issues
Conclusion? Fix and automate your development pipeline. Make use of tools and techniques like Continuous Integration and Deployment and Automated Testing. Make the development and deployment process work for you, not against you.
Finally: “Make your configuration complex enough and you will end up implementing a new programming language – poorly!” a wise man once said. (Or maybe it was just me?).