Been thinking lately about how I don’t want to have to eternally babysit every web application I’ve ever made. So it seems like I have a few options for future applications:
- Use existing community-driven projects and customize.
- Create application that allows for script files and database to be dynamically added, changed, or deleted.
- Create application that “virtualizes” the database and abstracts script files.
When I first started working with web application development… I used existing community-driven projects and customized them to try to match the needs of the user(s). At some point, however, I got tired of running up against places that were too hard to customize… which eventually lead me to create web applications from scratch. Web applications from scratch are great (at first,) because they are tailor-made from the very start. But custom applications readily become a liability for users when the application developer has decided to stop supporting the application.
One of my earlier applications tried the second method (of creating an application that allows for user additions, changes, and deletions to the application itself,) and it all seemed to work for a while. But there are dangers in allowing users to change the very foundations they are standing on in order to make those changes. (For example, would you want to be a high-rise window washer with the ability to cut your own safety rope by inadvertently saying a few words?) This second approach seems great at first but the dangers that come along with this method may not be worth the risk.
The third approach of “virtualizing” the database might be a safer approach to a user-customizable web application. The term “virtualizing” here refers more to the idea of “abstraction” instead of other modern-day definitions for virtualization. When a database is “virtualized” it is basically made up of unchanging table columns that point to changeable table rows. It allows for user customization for the web application… while not actually changing the database structure. This method can optionally include a similar “virtualization” pattern for actual script files, as well. This approach would potentially complicate moving this database to another framework or application, however, because database tables would end up being further abstracted than usual.
At any rate, it still seems like there should be something easier between all of these approaches; and there probably is (aside from the “just have someone else do it” option…) I just have to find a better approach, I guess.
