The Domain Access module in Drupal 8 is a suite of tools to help you to run a group of sites from a single Drupal instance, and from a shared database. It’s very useful when you are planning to have few similar set of sites, with different content. The module allows you to share users, content, and configuration across sites, making it easier to push global changes while still maintaining individual theming elements on the sites.
I did some assessment of the Domain Access in Drupal 8 and decided to put together a quick guide to help decide when to use it, and when not to use it.
Impacts Performance: Domain module filters the content into
If authenticated user are logged-in, then all the blocks get counted and only domain specific blocks render. So if we use domain specific blocks, it might lead to reduced performance.
Downtime: Any issue on one site will lead the downtime for all other sites.
Development Efforts: With every functionality that you add, the domain functionality needs to be extended to make sure that the functionality get loaded when the site is rendered.
Theming Challenges: Rendering different themes on different sites is a challenge. If your requirement is to render individual themes, and if some/most parts of it are not reusable, then you are faced with huge problems.
User Experience: If the content editor has access to publish the content on multiple domains, there is a possibility that they enter the wrong content on the wrong domain, leading to a bad user experience.
Increased QA Efforts: Any changes to the codebase or adding new feature on any site will require regression testing for all the sites.
Site Specific Configurations: If there are certain requirements that need to be implemented on a specific site, that might need extra effort in development and management. e.g if Google Analytics needs to be configured domain specific from a single database, we need to customize the added GA (just an example) token key to the specific site.
So you have weighed the pros and cons, and decided to go ahead and use the Domain Access module. What next?
Here are a few key things that will be helpful in ensuring a faster and scalable site:
If you are going to create multiple sites in a single instance, then opt for dedicated hosting. Try to keep the db server separate from the web server.
User will authenticated using single sign on. Stopping it will lead the duplication in the database. If users are registered from one site, they won’t be able to register from the other site. So we need to give a clear message so that users can use login just once.
Redis: Irrespective of how much traffic is expected on the site, we can use Redis for authenticated cache as well as anonymous cache. This works on the LERM algorithm which might be helpful here.
Varnish (Optional): As a reverse proxy, we can use varnish with Drupal 8. It will help to reduce the downtime of the site in case there is any issue. (Note - we can discuss and then we can move Varnish in or out)
CDN: For assets/security we can use CDN to reduce the web server load with CORS implemented. All the media/JS/CSS/Font will go to CDN server.
So that was my assessment of Domain Access in Drupal 8. If you are well versed with using Drupal 8, hope this helps you take an informed decision on whether to opt for it or not.
If you are new to Drupal 8, and want to quickly the get hang of it along with the rest of your team, you should definitely take a look at our Drupal 8 Training program.