While integrating any third party tool with its own data storage capabilities, I usually end up with a question

So far I could figure out following Pros and Cons in both the cases.

PROS for storing on Drupal(local entities):

  • Easy reporting with views.
  • Being local entites to Drupal, we can leverage drupal out of the box functionalities like add/edit/delete forms.

CONS for storing on Drupal(local entites):

  • It creates dependency on Drupal, while the third party tool has all possible capabilities to run as standalone application.

Another possible option could be storing at both places Drupal and third party tool

  • But that would cause data syncronisation problem, and will require development at both ends to push data changes.

An example of such integration I recently came across is Camunda(BPM tool).

What will be a suitable place for data storage? Should we keep it on Drupal, or should we leverage third party storage capabilities?

  • What's the question?
    – Jaypan
    Sep 28, 2016 at 5:57
  • @Jaypan updated the question
    – arpitr
    Sep 28, 2016 at 6:00
  • what is your drupal version?
    – Yuseferi
    Sep 28, 2016 at 6:11

1 Answer 1


Personally, I go usually with a caching system within Drupal. How this is implemented really depends on the external system, and how it works, but essentially I'll pull the data from the external source when first requested, and save it within Drupal somehow, whether that be into a node, or a custom entity, or some other data entity unrelated to Drupal entities.

The reasoning behind this is that pulling data from a 3rd party application into Drupal, then delivering it to the user, adds a lot of overhead and processing time. Essentially the browser makes a request, Drupal then starts to build it, makes it's own request (same as a browser) to the 3rd party app, gets the data back, finishes the Drupal page build, and sends it to the browser. This can make for some particularly long page builds. Whereas, if you pull it the first time from the 3rd party app and cache it, it takes longer for that first request, but subsequent requests will already find the data within Drupal, making for faster page loads.

Some things to consider however:

  • Will the data change every request? If so, then it should not be cached within Drupal.
  • Will the data never change on any request? If so, then it should be created as either a Drupal entity, or a non-Drupal entity, within Drupal, permanently
  • Will the data ever be deleted? If so, then it should be cached within Drupal, and periodically checked to see if it's been deleted. If however it must definitely not be accessed after it's been deleted, then it should not be cached within Drupal, else you risk showing the data to the user after it's been deleted.
  • Can you cache the data safely for a period of time? For example, maybe you can make the Drupal cache expire periodically.
  • Will you need the data to be accessible as fast as possible, when it's cached? You may want to create a cron mechanism that makes requests to the 3rd party for any new items, caching them immediately so they are ready right away when necessary.

Each 3rd party app is different, so there is not a one-size-fits-all solution to this. The various limitations and requirements need to be researched, with a solution created accordingly.

  • 1
    To add to this, the simplest way to make it Drupal supported is to create an entity and default bundle or however many bundles you need, key in some properties like remote_id, and build a batch form to do an initial import. You could batch import stubs, build your render on view, and cache that. But there are so many nuances and ways to do it, its kinda broad, have to really think it through.
    – Kevin
    Sep 28, 2016 at 18:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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