Consider the following scenario. You’ve been tasked with developing an application with whatever resources you see fit. This application has two main branches of functionality in which there’s reasonable overlap. After some investigation, you find three frameworks worth considering.
| Task A | Task B | |
|---|---|---|
| Framework A | Excellent | Poor |
| Framework B | Poor | Excellent |
| Framework C | Good | Good |
Assuming all else is equal, there’s no clear winner between these frameworks. How do we decide what’s best in this situation? A member of the Drupal community asked this very question back in 2005, specifically with MediaWiki, PHPBB and Drupal.
I would argue that there are overlooked costs in integrating frameworks A and B. While it does result in an application that excels at both tasks, the overall complexity of the system is increased and we begin to run into some fairly common issues.
- Single sign-on and sign-off. Authentication should be persistent between both systems. If a user logs into one, consistency would dictate that they be logged into the other (likewise with logging out).
- Model parity. If Framework A relies on some internal model that overlaps on both tasks, then that model will need to be translated and synchronized into Framework B and vice versa. A simple example is user accounts, but we can envision more complex examples such as replacing MediaWiki talk pages with PHPBB forums.
- Task appendices. Since Framework A will be used exclusively for task A, this task must be disabled in Framework B. Alternatively, requests for task A in Framework B could be redirected, but this requires careful mapping and possibly, as mentioned above, model parity.
- Increased custom code. It’s likely that neither of the frameworks have been specifically designed as a plugin for the other. As such, it will be necessary to write custom code to glue the two together. Whether or not this code can be written as plugins depends on individual frameworks considered.
- Incoherent user interface. While not a functional requirement, it can be aesthetically jarring for users to move back and forth between two interface designs. Care can be taken to make one look like the other, but ultimately the two frameworks are likely to diverge on some design choices.
Integration of two mature frameworks is often a messier task than predicted and alternatives should be considered before committing to that approach. Framework C may never be the best at either task, but it demonstrates that it’s addressing their functionalities. It’s the coherence of a single system that leads to a cleaner, more manageable application.
In the event Framework C doesn’t exist, it might be worth looking at whether or not it’s necessary to tightly couple A and B.