Web application integration with Drupal

Question

We want to build a web application, that is specific to our domain, but also include forums, blogs etc in this application. Some integration points to Twitter and Facebook are also required. There will also be a desktop application that connects to our web application for uploading data and downloading configuration and reports.

The question is, can we extend Drupal to host both the regular modules and our web application? (There will be business entities and their properties and daily data uploaded from the desktop application) Or can Drupal be integrated with external applications? As an example, users and roles need to be same and consistent across both. We may also want data from the web application searchable in Drupal.

I know this is a bit vague, but I cannot reveal more. I am very new to content management and I just wanted to know if someone has built this kind of application.

Answer 1

As Drupal is open source, you can pretty much do as you wish with it. A couple of points though:

Changing Drupal's user/role structure would be tedious and unnecessary. You would need to have your desktop application authenticate from Drupal's MySQL database.

Drupal has hundreds of plugins for just about everything, so Drupal could no doubt run the whole "web" side of things including visitor stats etc. You would just need, again, to connect your desktop application to the correct MySQL tables and show the data as desired.

Don't forget to check other content management systems such as Joomla! (and many others). Each has its pros and cons. www.opensourcecms.com allows you to easily test CMSs and I've used it extensively in the past.

Just be sure to map out all the components first. Every hour planning up front saves many hours of headaches later.

Answer 2

I worked for over a year using drupal extensively, but I ended up abandoning it. Drupal, and other CMS systems out there, have very rigid limits and rules. I'd use Drupal for projects where you have simple requirements and few or no business rules. Drupal gets complicated almost immediately when you want to do complex things (especially pay attention at the menu system, forms, and the translation system if you need to be multilingual).

If your system will really be large, with all the things you mentioned, then I'd rather use a PHP framework to implement your business logic, and integrate external products as they fit (a forum, a blog, a twitter client, etc...).

But the advice is: don't trust anyone :) Download it, and play with it for a week. You'll be able to make your mind and be more confident about your choice!

Answer 3

Hello Tanmay. I try to rephrase what you wrote, just for you to check that I got your question right. You basically need to create a web application that:

1. Implements some of the standard functionality of Drupal
2. Have some custom functionality that should "blend into" the Drupal one (same users, same permissions, etc...)
3. Be able to upload/download content (or data) from desktop applications.

If I got you right, the short answer is: yes, you can do that with Drupal.

Now for the extensive one: - Drupal has literally thousands of modules, so I expect you to get most of the things you want by simply installing the right combination of readily available modules. - Of course, any custom functionality can easily be implemented in form of a module too (quite standard thing these days). - The interaction with a desktop application is normally implemented via webservices rather than querying the DB directly. Drupal comes natively with a xmlrpc server and client, but you can scale up to SOAP - if you wish - via a couple of contrib modules.

Some additional thoughts:

• If you choose to use Drupal, and you start from scratch, then you have to be aware you and your team will need to dedicate some time and effort to understand how Drupal works. Although - differently than Palantir - I stuck with Drupal, I agree with her/him on the fact that Drupal gets complicated complex right off the bat. This is the trade-off you have to pay in order to have a platform that - rest assured - is very flexible, extremely pluggable and rock-solid (otherwise it wouldn't have been used to redesign the whitehouse, nor Drupal would have got for the second year in a row the "best PHP CMS" award, I suppose).
• The good news is: there are some excellent books out there, and I would certainly recommend "Pro Drupal Development" for an in-depth and all-around explanation of the system. Just be sure to get the 2nd edition, as the first deals with the now obsolete 5 seres. That said...
• A very good thing about Drupal, at least in my opinion, is that most of the tweaks you might need to do to an existing functionality can be implemented by hooking into the original code from a custom module too. This IMO is the biggest advantage of Drupal: you never have to touch other developers' code to achieve your goals, and this means - for example - that you will be able to keep your core and contrib modules up-to-date without breaking any customisation you might have done.
• Drupal is heavy. Compared to other CMS it sucks plenty of processing power and RAM from your server, and - unless you are going to have a very small site - I recommend to deploy it in conjunction with nginx, rather than Apache.
• Drupal scales well, thanks to a good mechanism of caching and "throttling up" mechanisms. Strange as it might sound, Drupal scales very well on large traffic websites, so that big increases in traffic do not necessarily imply big increases in resource usage.
• The user experience out-of-the-box on a Drupal site is quite poor. There is a massive work being done on this at the moment (here and here (video)), but improvements won't be available until D7 is released [soon, but then you will have to wait for the modules to be ported], so it is advisable to allocate some time to create an administrative theme, if the admins of your website won't be of the technical type.

At the end of the day, my advice is: if your site is going to go big / complex / with complicated business logic and lots of functionality, then Drupal is probably a good candidate. If your site is contrarily a small-scale one with standard functionality plus a few custom bits, maybe Wordpress / Joomla could fit your needs better [not because they are 'less powerful' but because Drupal strengths would be unused in this case, while Wordpress/Joomla simpler architecture would probably represent an advantage in this scenario]

Other options would certainly be frameworks like CakePHP or Django, for example, but that - IMO - is a totally different approach to the matter, I would say.

HTH, Mac.

Answer 4

Short answer: Drupal is well suited to build something like that, especially if you are willing to integrate your app/logic into Drupal as a suite of custom modules. The other way, integrating Drupal into an external application, can also be done, but will give you more friction, as Drupals architecture is pretty much geared towards being a framework in its own right.

---

Longer answer: I have a pretty much opposite opinion/experience compared to Palantirs. I've been working almost exclusively with Drupal for a year now, in the context of two fairly complex/'enterprisy' projects (after several years of 'on the side' usage for smaller things). While I agree that it imposes some rigid rules (but not limits!), I consider this to be an advantage, as those rules give a clear guidance and provide proven ways on how to do things. The three parts Palantir mentions are good examples for this:

• Menu system - Provides a well structured and effective dispatching mechanism that is easy to extend with your own stuff, while giving huge flexibility to tweak/manipulate existing/default paths. (Note that 'menu system' in Drupal denotes the whole topic of managing your URL space, not just the subset of 'visible' menus that is usually associated with the term)
• Forms API - A declarative approach to web forms, with a well designed processing workflow and a whole lot of built in security features that you would otherwise have to take care of yourself. Also highly extensible, with straight options to adjust/extend already existing forms on demand, add new validation rules to any field or whole forms, multi step forms, javascript based form adjustments, etc.
• Translation system - This is pretty complex, simply because internationalization is fricking hard to do. But it is built in, again giving clear guidance on how to do things in order to work in a generic way (though there are problems with quite some contributed modules that are not using/supporting it the way they should).

I could give more examples for parts where I appreciate the 'rules', but this post is getting long already, and I still have to cover some downsides ;)

So to sum up the positive part - if I where given the rough specs you posted, I'd say 'no problem' and go with Drupal, being confident that it would be a solid foundation for the custom parts, while providing all the 'standards' like forum, blogs, twitter/facebook integration and many, many others in the form of already existing solutions (even though those might need some adaption/tweaking).

---

Downsides: As always, there are flaws, and some of them are substantial, depending on requirements/circumstances.

• Learning curve - Drupal is quite complex, and 'grokking' its concepts takes time. 'Playing with it for a week', as Palantir suggests, will certainly give you a general feeling/broad impression, but it is in no way enough to allow for a serious judgement of its pros and cons, as those will only surface while coding in/for it. So if you are already deeply familiar with an established web development framework, this might be an issue. If you have to learn one anyways, this should be less of a problem.
• Database restrictions - As of Drupal 6, database support is MySQL or PostgreSQL only, using a Drupal specific 'abstraction layer' (which obviously isn't one ;)
  Drupal 7 will move to PDO, which should (finally) end this questionable state.
• Test/Stage/Production migrations - Parts of Drupals 'out of the box' flexibility are due to many things being configurable in the administrative backend, which implies that many important configuration settings are stored in the database. This makes migration of data and/or configuration between several instances pretty difficult/tedious, once you left the (early) stages of development where you can get away with complete dump/restore operations (see e.g. this question & answers)

These are the main ones for me, but you'll probably find more :)