In this article I want to explain the background to some of the architectural choices I've made in this live prototype.
The big hitting pieces you can see from the image are:
It's important to state early on that I am neither a Drupal engineer or a php developer.
I am however someone who tries to choose the best tool for the job and having had the fortune/misfortune of integrating with various CMS solutions over the years, to me Drupal appears to be a clear winner for flexibility and editorial experience.
Having spoken with various users and editors over the years, Drupal on balance seems to be the least hated.
Another hugely important factor is 3rd party integrations which Drupal has in abundance.
Now I have worked with Drupal in the past and whilst the editorial experience was great, many other aspects of Drupal development were dreadful.
Some of the main awful aspects:
All this being said, there were and are ways around all of these problems but all come with such as lot of effort and time.
In rocks Drupal 8...
The Drupal community have taken a great leap forward with Drupal 8 by exposing all of the system entities via a REST API. This allows us to consume Drupal 8 content as we would any other service.
There are however some issues with the REST API approach that I don't have the appetite to deal with such as the same annoying caching requirements, authentication issues etc. etc., there are however ways and means of bypassing all of that nonsense and utilising Drupal 8 solely for content management, fully decoupled from my front end site.
I am a huge fan of Azure Blob Storage and I use it in nearly every solution I architect and build nowadays.
Blob storage is very cheap, very fast and I can pretty much store anything I like in there.
I have decided to store cleaned and transformed versions of all the Drupal 8 entities as JSON files in blob storage - this is a huge proponent in aiding me to fully decouple my front end site from Drupal 8.
Now whilst blob storage is great for storing and retrieving files; finding them is a very different story, especially if you have thousands or millions of documents to wade through.
Now Azure Search might be considered a slightly controversial choice for use in an enterprise publishing site (what this prototype is for), especially among the more puristic users of Elastic.
I really like Elastic, it's without doubt one of the best bits of tech we have at our disposal and if Azure search becomes too limited; Elastic is the fallback position.
The first reason for choosing to run with Azure Search was that I had already introduced this technology into the company therefore it is already a known and prominent feature in the companies future.
Another important reason is the company's technical landscape is heavily SQL based; learning search engineering would be a huge learning curve for the technical staff, the Azure Elastic wrapper bridges the gap to make it much more accessible.
So far I am finding Azure Search to fair very well however with search the devil is always in the detail and I'll know how good a fit it really is over time.
To host the website and API's I'll simply be using Azure App Services.
The applications will be written in C# using the ASP.Net MVC and ASP.Net Web API 2 frameworks.
I haven't used Cloudinary before but thought I'd try them out, I will need a good Digital Asset Management (DAM) solution and this company seems to fit the bill; plus they have a very generous FREE package which is always nice.
This was a very brief introduction to some of the choices behind my architectural decisions for an up and coming project.
This blog is the working live prototype and so far so good... but time will tell.