Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?
share|improve this question
5  
Unfortunate fact business people rarely understand about deadlines: You can't buy time. He can be willing to break all the banks, but money doesn't make a project complete faster, it just makes him feel better; not the same thing. –  Jimmy Hoffa Apr 29 at 14:15
    
From the description, I'm not seeing anything that would lead me to believe that a regular ol' PHP app wouldn't suffice. It really depends on how you plan to use the database. –  GrandmasterB Apr 29 at 15:23

3 Answers 3

up vote 11 down vote accepted

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.

share|improve this answer
4  
I didn't think of the VM deployment. That is pretty elegant and I think will work very well. Our group keeps running into is clients with a "little" bit of Tech knowledge. Our last client wanted to architect the database for us and chose to use Star Schema for transactions. That was a complete disaster. –  Pete Apr 29 at 14:15
    
Or perhaps a hosted, multi-tenant deployment –  GrandmasterB Apr 29 at 15:22
    
The virtual machine approach is spot on. It solves most of the problems and makes for a very easy installation. –  BobDalgleish Apr 30 at 1:08
    
If you want to get really sci-fi with your VM deployment consider Docker. It probably won't be production-ready in 4 months, but this is a pretty cool demo: Discourse recommends docker as the default deployment option github.com/discourse/discourse_docker –  Daniel J. Pritchett May 2 at 16:47

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.

share|improve this answer
    
hmm... Good points as well. Our director was present at the meeting and kept telling the client that something has got to give, but the instant he said he'd throw more money at us, our director left. I'm pretty inexperienced in the game of politics and business, but I guess the bigger picture is more complex. –  Pete Apr 29 at 14:33
1  
@mister_rampage no, the bigger picture is quite simple: Your director saw dollar signs and decided "Great, I'll just demand my guys break their backs if need be and we'll rake it in.", given the fact that what is being asked for can't be done on time, you can logically predict what will come next: It will reach near the deadline, you and your colleagues will be busting ass and won't get it done, in that situation you may know best how your client or director will react. Usually the director will just try to save face apologizing while trying to still get the money, clients are unpredictable –  Jimmy Hoffa Apr 29 at 14:45
1  
@mister_rampage when trying to predict and account for their actions, keep in mind: Both your director and this client have actively and openly committed to do something which they have both been told clearly cannot be done by the experts who would actually do it. So you should assume neither of them to be particularly bright, keep your predictions to what inexperienced idiots would do. –  Jimmy Hoffa Apr 29 at 14:48
2  
@mister_rampage I'll admit to a bit of cynicism with this but "always keep your resume polished." –  MichaelT Apr 29 at 15:06

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."

share|improve this answer
    
I'm going to have to use that quote. :) –  Pete Apr 29 at 20:40

protected by Community May 3 at 17:32

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.