Hi all.

I am searching for a development-platform for a customer. This is not for a one-time project but for future development, for websites, webservices, backend for existing systems, etc.

I always believed that the PHP-platform had the most options, but after having spent some time in various CMS solutions on .NET platform, I looks like that the CMS-systems are simply better on the .NET platform. This surprises me since we have more than 60+ CMS-systems on PHP according to wiki. I haven't look’ed through all tho. :) It is not possible to have experience on all systems so my comments may not be correct. So don’t hesitate to correct me if I am wrong.

My customer has following requirements:
1. It must be SOA. I would state that a webpage is nothing more than a client on equal terms like an app on i.e. Android.
2. It is essential that there exist some form of frontend-component-engine to speed up development.
3. It must implement the MVC-pattern to make development flexible and easy to maintain.
4. It must have web services, primarily REST/JSON.
5. It must have template-/theme-engine.
6. It must have support for data-providers.
7. It must have jQuery as base for both frontend and backend.
8. It must have unit-testing.
9. It must support a number of databases, in this situation MySQL, MS SQL, Azure SQL.

I am not trying to start a war of religion, but I need facts so I can advise my customer. And I hope you guys can point me in the right direction.

Is Drupal the right choice? And if yes, what modules do I need to reach the goal?

Comments

Drupal 8 will answer most of those out of the box, apart from support across MySQL and Micrsofoft SQL (a lot to ask!). Drupal 7 less so. On the question of Drupal and MVC see http://www.garfieldtech.com/blog/mvc-vs-pac which largely holds good for Drupal 7, though not Drupal 8.

In D7 the basic architecture is that a single request gives a single page response, with web services integration is with contributed add-on module(s). D8 will move to being able to serve pages, elements of a page, any chunks of data in non-html formats, in response to requests.

Not sure what you mean by jQuery as base for backend. If by backend you mean the kind of backend / frontend distinction in Typo 3 this does not map to Drupal architecture. In D7 jQuery and various libraries are included, with version is 1.4, upgradable by contributed module, 1.4 being the version current when D7 was released: D8 policy will be to allow Drupal core to change versions of jQuery with minor version upgrades.

Note D8 will look quite similar to D7 but is totally rewritten with strong integration of Symfony framework for handling http requests and routing, and with a strong move away from Drupal's legacy of procedural code. A D7 to D8 upgrade will probably be very difficult.

Commercial pros and cons: for good developers who are not yet Drupalistas, Drupal is notoriously easy to get wrong and under-estimate, both losing money for the developer and delivering a poor and troublesome product to the client at the same time. On the plus side, once you have earned Drupal skills (probably the hard way) there is a great deal of work and opportunity.

Thanks for your input. Very valueable. :)

It sounds like its worth waiting for D8. Do you know of any dates ?

About the cross-database, you write "a lot to ask". I don't know how Drupal handles the database, if it is through objects or pure sql. If it is pure sql it should not be that big of a problem, but again, I dont know how Drupal handles it.

I think I need to buy a book on D8. :)

Do you know of a comparison-chart on Drupal vs other systems i.e. Joomla?

It is too early for a book on D8, which is not fully stable and the best people to write the book are busy writing the code. The source is api.drupal.org which reflects the rich comments in Drupal core code. D8 is an alpha and will probably be out early 2014, and it will probably take a good year before the vast richness of contributed code for Drupal 7 (and even more for Drupal) gets anywhere close to getting up to speed.

Even before Drupal8, Drupal 7 has a lot of abstraction, including its own database layer which should allow the thousands of contributed modules all to use the same syntax, and raw db queries are discouraged. Various databases are supported, and for performance reasons there is more interest in extending support for MongodDB than in MS sql. After all, integrating a Drupal site with an existing db is usually a mistake architecturally: data should be migrating into a Drupal-ceentric environment where it can be access by the Drupal APIs, so calling on a MS SQL db is not that useful. There is a contributed module adding support of MS sql which I have not tried. Of course modules which, contrary to good practice, step outside the official db API can still fail on anything other than Mysql. Incidentally, putting any db query in the theme, with our without using the db API, is unfortunately common and is considered the ultimately sign of a developer who may be competent otherwise, but is hopelessly incompetent at Drupal.