OK, we’re looking at the development and deployment question.
This is a big area of interest for me. I’ve actually created a framework for development and deployment of web applications (primarily Drupal) and it is at:
https://github.com/SSVC/pullpush/wiki
…and this addresses the key problem of getting the actual data out from a live site and bringing it into a new version of the site which can then be deployed. For Drupal based sites I needed to write a module which could export and import site data – and we think in terms of site data as being nodes, taxonomy terms and users.
This framework works well and is currently being upgraded with more error checking and cleaner design etc.
So, the point is – we need separation of site design/functionality from site data (pages, comments, articles, etc).
This lead me to thinking further about how to separate content (data) and design/functionality.
For Drupal one way to do this would be to have two separate databases behind each site. One would contain site configuration and the other would only contain site data. This might/might not be feasible/possible – but would give us a way of more easily moving data from one site to another.
But – here’s another idea.
I’ve come across situations where companies use Access for a company application. What they do is have one central Access database which just contains tables. They then have another Access ‘database’ which is opened and used by the company staff and which contains all the forms, reports etc. This ‘frontend’ database links to the ‘backend’ database by using linked tables. Linked tables are basically created as links to tables on another Access database – and these linked tables can be used by forms and reports. Maybe we could do a similar thing with Drupal?
(BTW – I do not recommend using Access this way as Access databases are file based and not RDBMS’s they are very prone to file corruption. At least use SQL Server Express for the backend.)
So, we could have a backend Drupal site which contains the content types and contains all the nodes, taxonomy terms and users. This would only need a simple management interface to allow editors to update content – we could stick to Bartik!
We could then have a ‘frontend’ Drupal site which has the design implemented and contains all the functionality required.
So, how do we link them? I suggest we could look at using REST and views and the Entity API.
Using the module https://drupal.org/project/restws on the backend means we can already POST data to the backend to create new nodes, terms, users. So our front end site would need to be modified so that new users accounts would be posted to the backend. There are already some modules which use external user databases – for example https://drupal.org/project/ldap. So, new nodes, users, comments and taxonomy terms would need to be ‘saved’ over REST to the backend site.
And as for reading the data to populate the front end site – surely we could use views and/or remote entities for this?
Here is an article describing how to integrate external entities into Drupal – http://wunderkraut.com/blog/remote-entities-in-drupal-7/2012-10-25
and here is someone working on entities implementation – http://www.drupal4hu.com/
It looks like we may be able to store all entities in a Mongo DB – but what about the editors? Drupal provides us with a great way to create admin sites which editors can use.
What I’m suggesting is that instead of the remote data being in a Mongo DB or similar it could be in another Drupal site/database which has an admin frontend which editors can use.
That way we get a nice robust Drupal site which contains the data – and then we can swap front ends easily as *all* the front end has to do connect to the backend site/database for its data. This would make deployment of new sites on big, busy, content rich sites much easier.
As an extra note we could still use https://drupal.org/project/data_export_import to get the data out from a live backend site/database and loaded into a separate dev/test copy.
Of course, thinking about it further we could simply put all of the data into a MongoDB database and have various frontends and admin areas accessing the data.
Any thoughts gratefully received.
Recent Comments