Scenario
I haven’t faced this requirement before, so I’m not confident with my solution. Our team drew up a plan to design a web application using a basic HAT stack for a project with a 4 month development time. We presented it to the client, who added two big new requirements. The requirements were:
- The application must be runnable on any web server (IIS, Apache, Nginx, Lighttpd, etc…)
- The application must be able to work with any database (MySQL, MongoDB, etc…)
His reasoning is that he has no control over the environments where the web application will be installed on. He plans on re-selling our solution to other customers.
We pushed back to the client saying that this would increase development time, but he has already committed to his clients. However, he said he is willing to put as much money into it to get it done.
Possible Solution?
The only solution I could think of was building the application in Perl CGI script as that seems the most universal, then having a variety of database adapters to plugin into an ORM, which is customized through a config file.
Question
- What alternatives are there to creating a web application where we have no control over what modules, etc.. are installed in the web server?
- Is this even possible?
2
The biggest problem you have is going to be with the databases. Within relational databases, you’ve got some dialectical differences between them (things that postgres does differently than mysql or oracle) – different functions, different column types. This will make writing the proper query and creating the proper database schema difficult.
With Hibernate (Java stack), it is possible to forward engineer the database. You create the objects and the ORM layer creates the corresponding database. That said, this is means that everything you do is through the ORM. (I think there is a corresponding thing in Ruby somewhere, not that I’d recommend ruby).
Adding in “any database” to that which includes things such as Mongo means that the ORM just doesn’t do it anymore. Even Perl’s DBI doesn’t have a corresponding DBD layer for Mongo – the paradigm for the database is just too different.
You could add another layer in front of the ORM to have your ORM layer with hand coded database drivers for Mongo, Couch, NoSQL Flavor of the week, etc… But now you are coding each layer again and again.
I believe that fundamentally your client doesn’t understand the nature of what he is asking for. Being able to run anywhere with no control over what is installed, or even the database that backbends it is an impossible task.
You may wish to consider pitching a deployment of a virtual machine. This has the entire stack that you want/need on it in one package that is then deployed to some other machine that is running the VM. You put the database, the web server, the application server, etc.. in that VM and that VM is deployed.
Anywhere they can run a virtual machine (anywhere), the stack can be deployed. Its only one thing that is needed on the target machine – the virtual machine player.
4
There are two problems here:
-
Getting the client to understand what’s possible, and what’s not. Especially, development can’t be accelerated arbitrarily by throwing money or manpower at it. It would be better to identify priority features that have to be present in the first release, and optional features that can be added later. The client obviously can’t have everything at once.
-
The technological side of things.
The different databases could be hidden behind an ORM, or you could fall back to something that’ll work everywhere (yes, I’m suggesting SQLite – here it’s less insane than what your client wants). Your webapp could run on its own server which is simply forwarded through the required deployment web server, which is a sane architecture in any case. However, you somehow need to run your webapp: You’ll need a JVM if you use Java, or the perl interpreter if you choose Perl, or a Python VM if you go that route. These are not always a given, e.g. on Windows. So you already have a dependency.
Now that the door is opened, we can add further dependencies – it doesn’t matter how many dependencies you have, only whether the client’s clients will have to install these dependencies manually. Providing installation scripts would therefore be preferable to trying to adapt to any environment.
4
1) You can design the core of your application logic without regard to a framework by essentially designing your own framework. Using CGI for Perl or C will be a good basis for the back end part. However, the database interface requires adaptation layers and shims.
2) You will need to develop adapter software for each database that you want to connect to. Since MongoDB and MySQL are completely different animals, you will have to aim for a least-common-denominator and make up the difference in your application.
3) Unfortunately, you won’t be able to meet the requirements in 4 months. Developing and testing the interfaces to the individual databases will require substantial testing effort. If you use the Perl DBI, for instance, you will be able to address most SQL databases, requiring only customization for primary key auto-generation. Developing an equivalent for NoSQL databases will require a lot of effort.
As for throwing more money at the problem … “Contrary to popular belief, nine women cannot deliver a baby in one month.”
1