As you have probably heard from elsewhere, Drupal 8 uses Symfony components. Most importantly though, Drupal 8 adopted a Symfonylike approach to structuring code with a servicesoriented architecture. This affects not only the core system, but also the ways of developing applications on top of Drupal.
The use of formally defined services not only encourages but also requires proper separation between components. This encapsulation results in clear dependencies and defined interfaces between the different pieces of a system. This new structure largely replaces the Drupal 7 procedural code that often lead to poorly defined scopes and hidden dependencies.
The use of an objectoriented structure also provides much better control over code quality. The use of an IDE protects programmers from basic errors which are automatically detected, and formally defined structures are much easier to discover, with code autocompletion and inline documentation reducing the need for extensive technical documentation.
Drupal 7 was only testable with browserbased integration tests that acted at the user interface level, but these were slow and very sensitive to changes. While these tests did test that the functionality worked as specified, they had no effect on encouraging good coding practices, which is one of the most important outcomes of testdriven development. Drupal 8 services on the other hand make use of a solid dependency injection system and can easily be unittested, making it possible to have a much deeper and more detailed test coverage of the business logic.
With this new tool, it is now possible to have a bestpractice “testing pyramid” with a lot of unit tests (mostly provided by Drupal core and contributed modules) covering the base tools, servicelevel tests covering the business logic, and a few browserbased integration tests providing a highlevel quality guarantee.
Clean integration of third-party components
Just like services provide an abstraction between the internal implementation and the public interface they provide, they can also be used to abstract away thirdparty integrations. Such tools are essential to provide clarity when integrating other products, like CRM systems, payment gateways, content repositories, etc.
Due to having limited and clean dependencies, we have noticed a great improvement of code reusability when using a serviceoriented architecture. Even custom components can be extended, and they can also easily be dropped into place from one project to another.
Extensions instead of overrides
One of the major advantages of Drupal compared to other frameworks is the powerful customization possibilities that make it possible to adapt offtheshelf modules to the exact requirements of each project.
However, with Drupal 7 and earlier versions, the customization model was based on alteration hooks that modified default structures after the fact. This pattern results in poor performance (data structures are first fully created according to the default implementation, then modified to match the custom need), and a code structure which is difficult to follow and to debug.
The new customization model is based on formally defined extension of default classes, a model that has been proven before in countless other frameworks. This model greatly improves the structure, quality and readability of custom code.
Fewer external dependencies
One of the most striking trends when comparing Drupal 8 projects to older Drupal versions is how few contributed modules are needed. This can be attributed to the improved consistency of the various subsystems. For example where blocks, formatters, or cache drivers were separate APIs each with their own peculiarities, they are now all behind a common plugin API. Similarly, all content (users, articles, menu items, etc.) are formally defined entities using a common API.
During the development phase of a project, the advantage of having fewer contributed modules is of course a simpler structure which is easier to understand and oversee. However, the biggest advantage probably comes in the long term, since fewer external dependencies means lower maintenance cost to keep the system up to date as well as less risk of introducing regression.
One of the most striking trends when comparing Drupal 8 projects to older Drupal versions is how few contributed modules are needed.
Code-driven development (the practice of managing all changes on a site via files under version control, without any manual steps needed for deployment) has been a best practice for a long time – and an absolute must for complex systems, but the tools available in Drupal 7 and earlier versions were add-ons that had to cope with inconsistent data structures and were error-prone, often leading to unexpected deployment tissues . The Configuration Management system introduced in Drupal 8 provides a much improved experience: the configuration structure is consistent throughout the system, and it has been built from the ground up to be exported and deployed automatically.
Thanks to a consistent format, deploying new configuration changes can now be done in a deterministic way without requiring a heavy amount of trial and error.
Drupal 8 exported configuration files match a formally defined schema, which makes it possible to automatically check that configuration changes are valid before triggering a deployment. This validation prevents conflicts between different changes pushed by different developers by detecting them early on in the development process.
All exported configuration elements also define dependencies which are added automatically by the module defining the configuration schema. This information is crucial to be able to remove functionality and the associated components from a system while retaining confidence that nothing will break. This makes it possible to get out of the common vicious circle for Drupal 7 sites where new functionality could always be added but nothing could be removed, causing the complexity to increase over time.
Keeping the performance of a system stable while it grows in complexity and usage (traffic) is one of the major challenges when building largescale applications. While Drupal 8 is not particularly faster in a simple test installation, the system behaves quite differently from Drupal 7 when it comes to scaling in different dimensions.
Scaling as new features are added.
Drupal 7 was a monolithic architecture, with most of the codebase loaded on every request. Even with some measures in place, the system got slower with every new functionality added. This has lead all complex projects to rely very heavily on caching, which became very problematic for authenticated traffic and transactional functionalities.
Drupal 8 takes advantage of a solid autoloading mechanism, meaning that each component is loaded as needed, so each request only loads the minimum necessary. The result for a large and complex project is that existing functionality is not negatively impacted when adding new functionality in different sections of the site. The performance of the system remains generally constant even when the complexity grows.
Granular cache control
Drupal 8 includes a completely overhauled cache system, with the most important change being the finely granular control over cache invalidation. Whereas Drupal 7 had to resort to blind invalidation of entire cache bins using wildcards, Drupal 8 makes use of a simple but very powerful cache tag system, making it possible to only invalidate the specific cache entries that are known to be affected.
For example, when an item displayed on the front page is edited, the cache entry for the rendered item is invalidated, as well as the cache entry for the entire page (since cache tags are bubbled up the rendering tree), but all the other items displayed on the front page are still cached. While we do get a cache miss for the cache of the entire page for the next request, all other items displayed on the page are still cached and the impact is quite limited.
The effect is an improved cache hit ratio, but we also see that in practice a request never reaches a fully empty cache. The result is a more evenly distributed server load and a much stabler perceived performance for the end user.
A common compromise for Drupal 7 was to set a minimum cache lifetime, but while this measure helped attenuate peaks it also meant that content modifications needed some time before being visible, resulting in much confusion and frustration for editors of the system. This compromise is not necessary anymore.
“Smart” render cache
Sometimes some elements on a page are specific to the current user, for example a simple message showing “Hello, <username>”. With Drupal 7, the fact that this message is different for each user meant that the page simply could not be cached.
This problem is addressed in Drupal 8 with the smart cache. This cache detects when parts of the page are so specific that it doesn’t make sense to cache them and replaces them with placeholders so that the page itself can be cached. The content of these placeholders are then loaded at a later point, either via edge side includes or via AJAX requests (similar to Facebook’s Big Pipe mechanism). This mechanism makes it possible to have very short response times and a greatly improved user experience, even for authenticated users.
Compatible with modern tools
Drupal 8 makes use of the modern tools we have at our disposition to improve performance, here are a few examples:
- A builtin twolevel cache (APCu for very fast local storage with a networkaccessible cache like memcache or redis as a secondary cache) provides very quick access to small but oftenused cache bins.
- Cache tags can be included in each response, so that targeted cache invalidation is not only limited to locally stored caches but can also be extended to Varnish and various CDN providers.
- Full support for PHP 7 results in 3050% improvement in response times, even for pages already being served directly from the cache.
- The use of the twig C extension can optimise the processing of twig templates.
Modern templating with Twig
What might seem like a simple change of templating language is actually a big improvement on multiple levels:
Separation of concerns
By introducing a proper templating language which is limited to just doing that, we are also clearly separating responsibilities. Frontend developers who are responsible for managing markup can do so without needing to be familiar with Drupal or PHP. Backend developers are also prevented from putting business logic, a malpractice unfortunately too common among inexperienced developers.
The majority of security vulnerabilities in web applications are at the pagerendering level, usually due to the lack of proper data sanitization resulting in possible crosssitescripting (XSS) attacks. Whereas Drupal 7 used to leave the responsibility to the developer to ensure that each variable is properly escaped, Drupal 8 uses Twig’s autoescape mechanism, resulting in a much more secure system by default.
Drupal has been known for doing things differently than other frameworks, and many of the internal systems had inconsistencies between them. A large part of the expertise required to work with Drupal 7 was in the knowledge of these inconsistencies.
Shorter and smoother learning curve
Having a more consistent and predictable structure means that developers need less time to become familiar with the new tools, and once the bases are there little effort is needed to become familiar with specific parts of the system. This applies both to Drupal 7 developers getting started on Drupal 8, but also for developers coming from other backgrounds. The increased consistency within Drupal also leads to more consistency between projects, resulting in an easier learning curve when new team members join a project.
Improved user experience
A great amount of work went into Drupal 8 to improve the overall usability of the user interfaces. While many projects include usability research for the frontend or customerfacing pages, there is often no budget to go beyond the very basics for the backend, so having optimised defaults can have a great impact.
The improvements benefit all people that are involved in a project, from developers finding their ways more easily in the administrative backend, to editors and other staff members having the satisfaction of using a tool that doesn’t get in the way of doing work that matters.
Increased team satisfaction
While Drupal 7 has been a great tool, its quirks have lead many developers to sometime spend more time creating workaround solutions than creating actual functionality. This kind of work understandably leads to decreased satisfaction in the team. In our experience, working with Drupal 8 has shown to be a much more fun and gratifying experience, and the increased motivation can also be seen affecting productivity in a positive way.
Working with Drupal 8 has shown to be a much more fun and gratifying experience.
Predictable development cycle
Starting with the release of Drupal 8.0.0 on November 19th, Drupal has switched to a semantic versioning scheme, with scheduled releases every six months. While these can’t break backward compatibility, they can introduce new functionality.
This switch to a predictable release cycle means that there is less of a gap between those working on Drupal itself and those using Drupal to build projects. Working directly on contributing projectrelevant improvements to Drupal now makes sense, as these improvements have a chance of being integrated within the next six months rather than having to wait an undetermined amount of time until the next major release.
Drupal 7 was released in January 2011, at a time when Drupal adoption in the enterprise market was just getting started, and in many aspects the system showed to be only a partial fit for the needs of enterprise projects. Most of the experience at that point was based on Drupal 6 (released in February 2008), when best practices like automated deployments and codedriven development were only getting introduced. Drupal 8 took a long time to be released, but it also integrates years of learnings and as such almost provides a different framework, which is fit for professional, largescale and complex systems.