Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Nov 25 2020
Nov 25

Building websites that are completely mistake proof is often considered to be a massive undertaking, which many-many times is not properly executed. Since there are so many parameters to fulfil and so many corners to oversee, mistakes tend to happen. You may not even realise that you have done something wrong in the development process, it could be much much later when you actually undergo a website audit that you come across the mistake that has been made.

Drupal websites are equally prone to mistakes. Despite the CMS being one of the best, there are still occurrences when things go wrong and the impact is felt on the engagement, conversions and consequently, the sales.

To not let that happen, I have compiled a list of mistakes that you need to steer clear of when building or working on a Drupal website. These are errors and oversights that many developers and content authors have experienced first-hand and you can certainly try to learn from their mistakes.

So here are the most common mistakes witnessed on Drupal websites.

A pencil is shown after having erased an error on the extreme left and the mistakes to avoid in Drupal are written in bullets in the rest of the space on a white background.

Where can you go wrong with the content? 

A good website is often considered to be the one with outstanding content, since that is what keeps the audience engaged and leads to conversion. Therefore, content is crucial for a website, both for the front-end and the back-end, so content should be one of the priorities in the website designing process. Due to this fact, there are a number of areas where the developers can go wrong with the content. 

The first common mistake witnesses with the architecture of content is using too many content types that you actually do not use. The unused content types are just going to burden your database and I am certain, you would not want an additional table in your database for three content types that you do not even use. Having content types with no nodes will have the same effect. Performing an inventory will help you get the mistake resolved.

Moving on from the unused to the used, content structures are extremely valuable for your editors who are going to fill them up and if they end up confused, what will be the point of it all? Standardising your content types is going to help you a great deal. 

  • Strike off the content types that are similar to each other, like news and articles;
  • Do not add new fields for every content type;
  • And most importantly, plan a structure prior to it, winging it may not work with your website content.

Content types have an effect on the performance of your website as well. So, if you do not want to drain the performance of your site by adding unnecessary complexity, you would be wise to avoid these mistakes.

What about your display mismanagement?

After content comes its display and Drupal is best in that game. With many different features available for use, Drupal can make your display game strong as well, you capitalise it wisely.

Creating a view for every list is both impractical and a waste of time. Focus on reusing Views as much as possible along with parameter based rendering.

Do you use PHP code in your database? If so, avoid doing that, instead you must write all the codes in the modules or themes itself.

Planning, optimisation and segregation are essentially the building blocks of a great website display. 

  • Planning to render the content types you need;
  • Optimising the Views you already have;
  • And segregating logic from presentation.

These three would have a visible effect on the display architecture.

What aspects of functionality can make your site lag behind?

The functionality of a Drupal site depends on the number of modules used and the way they interact with each other. Your code and how much of it you use is a major contributor in that. 

The most common mistake in this sense is the ignorance of code standards. This becomes more of a problem when there are more than one developers and everyone is using a different type of code. In such a situation, not only would the standard be lost,  but it would also become difficult for a developer to understand the other’s code. Therefore, the adherence to Drupal’s Coding Standards becomes a great help to uniformalise the code and make the functionality a breeze. 

Another obstacle in functionality are unorganised patches. Code modifications and bug fixes mandates the implementation of patches, however, they become a problem whenever there is an update. You can forget all about re-apply the patch or forget to change it in accordance with the new version. This can very well affect the functionality of your website, so organising them is essential. 

Having too many modules, too many roles and too much custom code, despite there being contrib modules for the same is bound to affect the functionality as well. Evaluate and re-evaluate your site for its needs to overcome these functionality hindrances.

Is your performance and scalability not up to the bar?

User Experience is directly proportional to the performance of your website; the more streamlined the performance is, the richer would the UX be. 

Here are three scenarios that can impact your performance in all the wrong ways.

  • The foremost is improper JS/CSS aggregation settings. This is supposed to combine and compress JS and CSS files from the modules in the HTML, leading to lesser load times and higher performance. And you will be saying goodbye to that with the improper aggregation.
  • The next mistake is that of inundating your site with too many modules. Drupal may have numerous modules to offer, but you can’t be using too many of them. Doing so would only slow you down and hamper your security as well. Only keep the modules that you would be using, messing up your code, performance, overheads and security is simply not worth it.
  • A sound cache strategy also goes a long way in performance enhancement. Caching too soon, caching at lower levels and not knowing what and when to cache all contribute in a lowered performance.

Drupal websites can be scaled by millions of users within seconds and that is what makes these sites great. Drupal offers many modules to enhance the performance and scalability, Blazy, Content Delivery Network and Server Scaling, being just a few of them. Not installing these could be deemed as a mistake.

Are you facing possible security breaches?

Security has become one of the major concerns amongst website builders. Therefore, protecting your business from the menace of hackers and all the havoc they can cause is paramount. 

You must have your security measures in place, however, there still may be certain areas where you may have become complacent and that just gives the break the hackers need. 

  • Primarily, you need to keep your website updated, all the core and contrib modules, despite you using or not using them. Updating a module would mean that Drupal’s security protocols are being updated with them and you make yourself secure with that. You cannot have your projects falling behind on various levels of Drupal’s security advisories.
  • Now, you can install the “ Update Manager” module to keep yourself updated. The “Available Updates” will give you a friendly reminder of applying the available security updates.
  • Next on the list of security blunders is not giving the Input Filters in Drupal their due importance. You might have configured the full HTML Input Format to every user or you might have completely disabled the HTML filtering. Both of these instances can give malicious code to enter your website and you know what happens then.
  • Continuing on similar lines, many sites also configure their servers improperly leading to unwanted access to them. On some occasions, servers are seen displaying their version numbers, which is like giving an open invitation to hackers. Server configuration and permissions should be a priority for every site builder.
  • It is also important to ensure that all the users accessing your site by logging into it are the ones you want. By implementing a password policy, removing old users and updating staff roles, you will be taking a step towards better security.
  • User roles are quite important in running a website, however, they can become overused quite quickly too, which not only slows down your website, but if they are misconfigured, it can lead to major security breaches.

Drupal has proven to be one of the best CMSs in terms of its security measures, it has you covered from every corner, but only if you let it. From granting secure access to providing granular user access control along with database encryption and preventing malicious data entry, Drupal will keep your site protected, provided you let it.

Have you made any infrastructural oversights?

The infrastructure of your website is decided by the stacks you have, which includes the server, database and the software layers like Varnish. Going into development with a firm plan for your infrastructure is the only way to go, an oversight in this area can be quite damaging. 

The common mistakes in this area are;

  • The size of the website’s stack is extremely large or extremely small.
  • Not preparing for growth by consistently checking the logs for error and the identification of the weaklings.
  • Having an ideal sized server, but not configuring it properly, which can make the traffic forego Varnish.
  • Allowing remote connections to the server can make the website more vulnerable.

Misconfiguration can be avoided by simply using the right tools for it. MySQLTuner is one amongst many, its performance suggestions help in improving the infrastructure as well.

Are you following your maintenance goals?

Maintenance of a website starts after the development is done and continues for the entirety of the life of the website. Considering this fact, you have to be very diligent with the maintenance process as making the wrong moves can be brutal.

Here are some of these wrong moves.

  • Not following Drupal updates is a more common mistake than you would think. By doing this, you are going to be hampering security and making your site vulnerable to Drupalgeddon attacks.
  • On the contrary, there are also times when we update the modules, but we forget to remove the older versions. This too happens a lot of the time and can cause many problems.
  • It is not just the modules that need to be updated, the development environment should also be up-to-date and friendly for testing.
  • Then there is the code, which is not using the Version Control System like Git, even the deployment of files should come directly from there. Also, using it, but not leaving messages for other developers related to the changes made can lead to chaos. It is, thereby important to always keep the VCS repository clean.

The crucial aspects of maintenance is time and consistency. When you do it timely, only then would it become a worthy practice. The review and assessment of your architecture in timely intervals along with all the logs, be it Apache or Drupal is a great headstart for the maintenance process.

Are you universally accessible?

Websites today need to transcend the parameters that used to confine them and their audience in the past. The sites and applications need to be built on a foundation that would make them fit for each and every user. Drupal has worked for the same, it aims to make websites accessible to all, including people with disabilities, by making itself an all-accessible tool. 

Web accessibility has become of the essence today, and persons with disabilities are at the core of it. Websites need to be designed keeping in mind their needs, be it a broken hand or a temporary sight loss. It isn't just me who believes this, World Wide Web Consortium’s guidelines agree with me as well. W3C two sets of guidelines are ardently followed by Drupal and your website should do the same, thus, support and foster inclusion. 

Despite its importance, many developers tend to overlook the accessibility features and that is where they go so very wrong. 

  • Not focusing on balanced contrast levels that can work under sunlight;
  • Not incorporating a form validation error verbiage to aid the visually impaired; 
  • Not using buttons over CTAs.

These may seem like minor errors to you, but they can go a long way in making your Drupal site accessible to everyone.

Is your site SEO friendly?

Being SEO friendly is almost as important as building a website. Search engines bring in big numbers of traffic, so optimising them is crucial; yet we tend to forget to fine-tune the SEO details and focus on all the other aspects. At the end of the day, a website is an online business and business cannot survive without its clients and being SEO friendly is the way to go. Going wrong in this area can be extremely detrimental.

Look at the following aspects of a website and see how many you are and aren’t doing. 

Are your URLs user friendly?
Are your images small in size, with filled out alt texts?
Are you making your paragraphs short to make the text easy to scan through?
Are you using robots.txt for pages that you do not want crawled?
Are you creating an XML roadmap to help Google easily understand the structure of your website?
Are you researching your keywords?
Are you adding internal links to make your less popular pages gain attention through the more popular ones?

A positive answer to all of these means that your SEO game is strong and a contrary answer would let you know your mistakes.

To avoid the contrary from happening, Drupal provides a number of modules to help you capitalise on the SEO front. The SEO checklist module is a proof of that as it helps you by ensuring that you are following through on the latest SEO practices. Then there are the modules that aid your URL precision, like Redirect, Pathauo and Easy Breadcrumbs.From easing the process tags to helping in communication with search engines to providing the essentials for editing, Drupal has all the right SEO modules in its corner and not using these would be a colossal mistake on your part. Read our blog, The Ultimate Drupal SEO Guide 2020, to know more about these. 

Can being multilingual pose a problem for you? 

Today, languages that are regionally spoken have started getting more prominence than ever before, especially in the international community. A french website would not be successful in India, if it is in French, not many people speak that language, so it would have to be in a locally accepted language. Being multilingual also opens the doors for many mistakes to occur. 

  • Using the same URL for all of your multilingual websites; 
  • Not giving the user a chance to avoid a redirect to the international website;
  • Using an automated translator, instead of actually hiring content authors fluent in the language;
  • Foregoing to translate the imbedded parts of the site like meta tags and descriptions;
  • Not focusing on the foreign market trends and the keywords appropriate to it;
  • And lastly, not writing the content in accordance with the local language and dialects. You can’t be calling ice lollies popsicles sticks in India.

You have to be totally attuned with the language of the region that you have followed for the multilingual project to work.

Is having a multisite presence worth it?

Depending on your business and its needs, having multiple sites can be a good solution for you. However, managing then can become a bit of a hassle and often lead to big blunders. 

Some examples of such blunders are;

  • Traffic is one of the major concerns here. Running multiple sites means you have one codebase and many sites on it, so if one is inundated with traffic, all of them could slow down as a result.
  • A mistake in the syntax of one site could mean a mistake in the syntax of all.
  • Updates become a headache as well. For Drupal sites, you have to run an update.php in order to update the site and doing that on multiple sites is going to bring on the headache.
  • And finally, if you do not use Aegir, you are going to regret going multisite.

Is your Decoupled Drupal approach the right one?

Drupal offers an impressive front-end technology to make your presentation layer as good as you want, yet it does not include all the front end technologies there are on the market. Taking advantage of JavaScript and Static Site Generator would mean to decouple Drupal and separating the front-end from it. Even if you want to take on decoupling, it may not want to take on. The decoupled Drupal can bring more drawbacks then. 

  • If you wish to capitalise Drupal’s in-built features, Decoupling would be a mistake, since you would end up parting with them.
  • If your front-end requirements and Drupal’s front-end capabilities are aligned, taking on Decoupling would only be an unnecessary effort on your part.
  • If you do not have either the budget or resources to tap into the hottest technologies, then even if you want them it is not going to be fruitful.
  • If you are only publishing content at one place, you would have no need for decoupling.

For a detailed explanation, read our blog, When to Move From Monolithic to Decoupled Drupal Architecture.

Finally, what about web hosting, are you doing it the right way?

Web hosting services that provide your website its own space on the internet are pretty common. There are far too many web hosts to count, yet the decision to choose one is not easy at all, since there are too many considerations to keep in mind. 

Some of the common mistakes to avoid which signing on a web host are;

  • Testing web hosts is not uncommon, it is the right way to know whether they are valuable. However, testing on your website that is primarily bringing in the traffic could be unwise, especially if you are using a free service. Therefore, not registering with a different party can be colossal.
  • Another mistake is trusting too easily without knowing the host for too long. Therefore, not partnering with one that has a long trial could be a mistake. The longer the trial period on offer is, the more reliable the host is going to be.
  • Taking on a web host is a huge commitment, so you have to be sure that you are in the good. Not doing your due diligence before the commitment is not the right way, comparing the pricing and features along with checking if they have blacklisted IPs.
  • Not tracking your hosting uptime and speed can also be a problem. Also not checking what guarantees for uptime are provided by the hosts for the same would not be wise. If there is a lapse between the guaranteed and actual uptime, keeping a track would give you the opportunity to ask for compensation.
  • Lastly, you cannot afford to not have a backup of your site and that too regularly. You will only have the recent version of your files and assets, if you back them up.

The Bottom Line 

Every aspect of your website is important, consequently, you have to be mindful of them all. If you are not, mistakes will happen and they will cost you your site’s performance, its security and your potential customers and sales. In order to keep that from happening, you have to avoid all of the aforementioned mistakes and ensure that your website is impeccably built and maintained on all platforms. 

Nov 23 2020
Nov 23

You must be familiar with words like intermediary, middleman and mediator. What do these words mean? Could they possibly denote a job profile? I think they can. An intermediary, a middleman and a mediator, all constitute a connection between two parties, they provide a line of communication that makes one access the other with ease; like a store manager, he allows the consumer to access the products of the manufacturer. Without him, sales would be pretty difficult to do. 

Bringing the conversation back to the topic at hand, an API is essentially an intermediary, a middleman or a mediator. The Application Programming Interface provides access to your users and clients to the information they are seeking from you. The information provider uses an API to hand the information over to the information user through a set of definitions and protocols. 

In decoupled Drupal, the API layer provides the connection between the separated front-end and back-end layers. Without it, decoupling would not be possible, since there won’t be a way to transmit content from the backend to the presentation layer. 

There are quite a few APIs that perform impressive functions, but today we would only be enunciating REST API. So, let’s delve right in.

What makes REST API important?

The REST: API logo is displayed in the centre.

REST API, RESTful API or Representational State Transfer is built on the constraints of the REST architecture. It is renowned to make development easy by supporting HTTP methods, handling errors along with other RESTful conventions. Since REST capitalises on HTTP, there isn’t a need for installing a separate library or software to capitalise REST’s design, making development all the more easy.

A representation of the state of the resource is transferred to the requestor, when REST API is used to make a request. It could be done in numerous formats, namely JSON, HTML, XLT or your plain old text, through HTTP. 

If you asked me what the best things about REST is, I would have to say it is its flexibility. The REST API is designed to be flexible because it is not tied to certain methods and resources. Therefore, it can handle multiple types of calls, transform structurally and return data formats as well. Such versatility makes REST competent to provide for all the diverse needs your consumers may have. 

REST cannot be defined as a protocol or a standard, rather a set of architectural principles would be a more accurate description. These principles make an API become a RESTful API. So, let us understand these constraints to understand REST API better. 

The Segregated Client and Server 

This principle states that the client and the server are to be independent of each other leading to more opportunities for growth and efficiency. Since the separation of concerns would allow a mobile app to make changes without those changes affecting the server and vice-versa, the organisation would grow far more quickly and efficiently.

The Independent Calls

A call made using REST API is just that, one call; it has all the potential data for completing a task in and by itself. If a REST API has to be dependent on the data stored on a server for each individual call, it would not be very effective in its job. It has all the necessary data with itself, making REST API very reliable. This principle is known as the state of being stateless.

The Cacheable Data 

Now you would think that since REST API stores such massive amounts of data in itself, it would increase your overheads. However, this is a misconception. REST was built to work with cache, meaning it can store cacheable data. This ability helps in reducing the number of API interactions drastically leading to reduced server usage and consequently faster apps. 

The Appropriate Interface 

Decoupling mandates the implementation of an interface that is not tightly connected to the API providing uniformity to application development. This can be achieved by using HTTP along with URI resources, CRUD and JSON.

The Layered System 

REST API works with a layered system; what this means is that each server, be it security or load-balancing, is set into a hierarchy. This constraints the component behaviour so that one cannot see beyond its layer. 

The New Code 

Finally, there is the Code on Demand, this principle that gives you the option to transmit code or applets through the API layer and this code or applet would actually be used in the application. This principle allows you to build applications that do not just rely on their own code. However, the security concerns have made it the least used of them all.

All of these are essentially the guiding principles of REST API, along with that they also lay emphasis on the work REST can do for you and your application; this, highlighting its importance.

Exploring REST API in Drupal

The Drupal logo is towards the left and REST logo is towards the right with an arrow in the middle.

Now that you know the importance and principles of REST API, it is time to move one to its exploration. REST API can be explored in Drupal through a number of modules, all you have to know is where to look and what to exactly look for. For the same reason, here is the list that would make consuming REST API seem like a walk in the park.  

Drupal Core Modules

There are certain REST modules that are so popular that they have become a part of Drupal core. These are;

RESTful web services

RESTful Web Services is a module that takes advantage of Entity API to provide you the information of all entity types, be it nodes, comments, taxonomy terms or your users. Being built over the Serialization module, it gives you customisation and extension of the RESTful API. It also has the ability to expose additional resources along with adding authentication mechanisms, which can be applied to any of the resources. 

Serialization and Serialization API

The primary purpose of the serialization module is to de-serialize data to and from formats such as JSON and XML. You can simply call it a service provider for the same. 

The Serialization API is based on the Symfony Serializer Component. Its numerous features have made it quite advantageous to the users. 

  • For one, it can serialize and deserialize data;
  • It helps in encoding and decoding to and from new serialization formats respectively, you can read data and also write it;
  • It can also normalize and denormalize data and set it into a new normalization format. 


HAL is an acronym for Hypertext Application Language. This module uses its namesake to serialise entities. With features similar to the Serialization module, it is often regarded as an extension of the same. The HAL hypermedia format has the potential of being encoded in JSON as well as XML. Being a part of Drupal Core, it is the most sought after format.

This is a module that lets you test drive as well. Yes, once it is installed and configured, you can test drive your site through the HAL browser by simply providing JSON data.

HTTP Basic Authentication 

You must be familiar with the term authentication, the working of HTTP Basic Auth is similar to that. What it does is takes a request, identifies the username and the password of the user and authenticates them against Drupal. It does so by implementing the HTTP Basic protocol, which essentially encodes the username and the password and adds the same in an Authorization header; and all of this done within a request. 

It is to be noted that this module does not use an interface, it acts as a support for Drupal’s Authentication Manager. 

The Alternates of Basic Authentication 

Basic Auth is an important module in the REST API, therefore, certain alternatives are also available to be used in its place. 

OAuth 1.0

The OAuth 1.0 standards are implemented by OAuth 1.0 module to be used in Drupal. It provides a foundation to the modules that want to use the OAuth. 

In Drupal 8, this module achieves the feat of leveraging the OAuth PECL Extension, leading to the implementation of the authentication provider

Simple OAuth(Oauth2) & OpenID Connect

Simple OAuth can be described as the implementation of OAuth 2.0 Authorization Framework RFC. In Drupal, it is a module that makes use of the PHP library OAuth 2.0 Server, which is a part of The League of Extraordinary Packages. Let me tell you something about this library so you know how valuable it is, it has actually become a standard for the modern PHP. With it being thoroughly tested, you can’t go wrong; still you would need to check your options at the time of deciding a project to use. 

Coming to OpenID Connect, it comes along with OAuth 2.0, being an identity layer on top of its protocol. It helps you verify the identity of the end users along with fetching their basic profile information.


The name OAuth2 JWT SSO does clear up notions of what it actually does, all three acronyms are at work. It can work with Drupal's very own OAuth 2.0. The reason being its ability to configure Drupal so that both centralized and remote authentication services can be used. 

Like its name suggests, it also works with JWT and SSO, which is short for Single Sign On. It can capitalise on any SSO, provided that it uses OAuth2 as its authentication framework, and JWT as its Bearer token. 

Cookie Based Authentication

If you have ever used a website, you would then know what a cookie actually is. Was it just today when you declined that ‘accept cookies’ request? These help a website to recognise users so that they do not have to log in again. 

Now, web applications tend to use cookie-based authentication, which they implement differently. However, at the end of each day, they will have some cookies set up that would represent an authenticated user. A cookie is transmitted along with every request and the session is deserialized from a store. 


More than 20,000  sites have been reported to use this very module. It is known to be fully feature-packed, its maintainers have the same thoughts. 

Coming to its abilities, REST UI provides an interface to configure Drupal 8’s REST module. Due to its handy configuration, you won’t find a need to play with Drupal’s configuration import page. This fact not only benefits the novice Drupal users, but also expedites your configuration by a substantial time margin. You can simply install it by using the default approach, Drush or the Drupal Console. 


REST API is pretty versatile in its features and Drupal has all the necessary modules to consume it in an optimised manner. If you had to choose a thread to hold your front and backend together, I would say that REST API would not let you down. However, that would only be possible, if you know how to capitalise it using Drupal. I hope I would have enlightened you about the same through this blog. To learn about other web services available in Drupal in addition to REST, read about GraphQL and JSON:API.

Nov 20 2020
Nov 20

Drupal is a renowned name when it comes to website development. The kind of features and control it allows you to have on your content is quite impressive. The traditional Drupal architecture has repeatedly proven to be valuable and now it is the time for Decoupled Drupal architecture to do the same, which it is on the path of doing. A major reason for the increasing popularity and adoption of the decoupled Drupal is the freedom to make the front-end using the technologies you like.

Since the Decoupled Drupal architecture separates the presentation layer from the backend content, an API becomes the thread that holds the two together to work in sync. So, it is important to choose the right one for your project. While REST API and JSON: API are quite sought after, GraphQL has also emerged as a front runner. So, let us find out what exactly GraphQL is, what it can do and how it plays in the Decoupled Drupal architecture’s picture.

Decoding GraphQL 

The GraphQL logo along with the words GraphQL is written in its signature pink across a white background.

GraphQL, a query language, came into being about eight years ago, however, its popularity came through in 2016, when it was made open-source. Its founder, Facebook, created a unique API because they needed a program to fetch data from the entirety of its content repository. It is a system that is easy to learn and equally easy to implement, regardless of the massive proportions of data you may have or the massive number of sources you may want to go through. 

When I said that GraphQL is a query language, I meant just that. It is a language that will answer all your queries for data using its schema, which can easily be deployed using GraphiQL, an Integrated Development Environment. GraphQL, being a language specific for APIs, is equipped to manipulate data as well with the help of a versatile syntax. The GraphQL syntax was created in a way that it is able to outline the requirements and interactions of data to your particular needs. The shining glory of GraphQL is that you only get what you have asked for, nothing more, nothing less. This means that the application will only work towards retrieving data that is of the essence in the request. The data might have to be loaded from varying sources, but it will still be accurate and precise, succinct to the T and exactly what you sought.

With decoupling becoming a need now more than ever and content and presentation layers segregating from each other, GraphQL becomes the answer for all data queries, essentially becoming the answer for data retrieval for your API and your web application. A query language and a runtime to fulfil every query within your existing data, GraphQL is powered to paint a complete and totally understandable description of your data using the API. Its robust developer tools have proven to make APIs faster, more flexible and extremely friendly to our developer friends. Therefore, achieving decoupling becomes extremely easy as GraphQL provides typed, implementation agnostic contracts amongst systems. 


The power and assistance of APIs have become all the more conspicuous in the decoupled world. With three prominent names taking the lead here, it becomes somewhat tricky to get to the right API conclusion. GraphQL, JSON:API and REST API, all three have their own virtues making them great at whatever they intend to do. However, it becomes almost impossible to talk about one and ignore the other two. My writing would not have been complete without a comparison of the three.

If you look at the core functionality of these three APIs, you will realise that GraphQL and JSON: API are much more similar to each other than REST API, which is a whole other ball game compared to them. Let us look at them.

Parameters GraphQL JSON: API REST API How much data is  retrieved?  Does not over-fetch data  Does not over-fetch data  Inundates the user with unnecessary proportions data  How is the API explored? Has best API exploration due to GraphiQL Uses a browser to explore the API  Relatively does not perform well and the navigable links are rarely available How is the schema documentation? Perfect auto-generated documentation and reliable schema Depends on OpenAPI standard and JSON:API specification only defines generic schema Depends on OpenAPI standard How do the write operations work? Write operations are tricky Write operations come with complete solutions Writes can become tedious with multiple implementations How streamlined it can be during installation and configuration? Provides numerous non-implementation specific developer tools but is low on scalability and security Provides numerous non-implementation specific developer tools and is high on scalability and security Provides numerous tools, but they require specific implementations and come with good scalability and high security


With GraphQL and its distinct fields of query, the developer is asked to specify each and every desired resource in these fields. You might be wondering why? The answer lies in its exactness. It is because of these explicitly mentioned desires that GraphQL never over-fetches data.

Coming to API exploration, GraphQL takes the cake for being the simplest and most conclusive. The fact that a GraphQL query comes with suggestions that can be auto-completed justifies my earlier claim. Moreover, the results are shown alongside the query resulting in smooth feedback. Its in-house IDE, GraphiQL, also helps in generating iterations of the queries, aiding the developers even more. 

If you told me that GraphQL specifications are more equipped at handling reads than writes, I would not object to you. Its mutations require you to create a new custom code every time. You can probably tell how much of a hassle it can be. Regardless, GraphQL can easily support bulk write operations that have already been implemented.

In terms of scalability, GraphQL requires additional tools to capitalise on its full potential and there are certainly numerous developer tools made available, and all of them are not implementation-specific.


The problem of over-fetching is not witnessed with JSON:API as well. Its sparse fieldsets produce an output similar to GraphQL. However, unlike GraphQL’s uncacheable requests, JSON: API can omit the sparse fieldsets when they become too long and hence, can cache even the longest requests. 

With JSON: API, the explorations are simple as well; as simple as browsing within a web browser, which is basically what the API acts like here. From scouring through different resources to different fields and debugging, you can do all of that with your browser. Can data retrieval be simpler?

In terms of writings, JSON: API is probably the best out of the bunch. It offers a wholesome solution for handling writes by using POST and PATCH requests. Even though bulk support is not available at the moment, it is in the works and would soon be in use.

JSON: API is again similar to GraphQL as it also provides various developer tools that are not implementation-specific. The fact that its infrastructure resembles that of a website, requiring Varnish and CDN, makes it different from the former. 


REST API has probably the most over-fetching system going on. Not only does it mandate multiple requests for one piece of content, it would also give you responses that are often even beyond the threshold of verbose. And the data that you end up with is so much more that you asked and needed. 

Again, REST API is completely different from the other two in terms of data exploration. And sadly, this isn’t a good kind of different. REST API is highly dependent on an OpenAPI standard, and if you are not adhering to that, things would seem a tad bleak for you. You will not be able to trust it for an auto-generated documentation or a validatable and programmable schema. The navigation through high volumes of data seeking interactivity is not too impressive either. 

Writing data in REST API is quite easy, almost as easy as reading it. Using POST and PATCH requests, every implementation is unique. Bulk support is not on the table. 

REST API’s infrastructural needs also resemble that of an ordinary website encompassing Varnish or CDN. However, its additional tools, although many, mandate customisation before implementation.

The GraphQL and Decoupled Drupal Dynamic 

GraphQL is a language that is undergoing developments as I am writing and you will be reading, but that does not mean that it is unstable. Moreover, GraphQL is being capitalised by several Drupal websites. The exactness in responses along with the always available introspection layer makes GraphQL truly worth it.

Let us now understand how it is the perfect answer to Decoupled Drupal by asking all the right questions or shall I say queries?

How does Drupal fully capitalise GraphQL?

Drupal can be rigid, it is a fact all of us know. Apart from this, Drupal can also seem to be too much with everything it has to offer. What GraphQL does is, it gives you the ability and the power to create and expose a custom schema that would eventually become the only roadway to all the data; information, operations and interactions, whatever happens within the system. And then, Drupal does not seem to be too rigid. 

You get a GraphQL module in Drupal  which is designed around webonyx or graphql-php. What this means is that the module is basically as jam-packed with features as the actual language is with all the GraphQL specifications.

  • The module can be used as the basis for creating your very own schema by generating a custom code;
  • The module can also be used to extend the already existing schema with the use of the plugin architecture, wherein the plugin would act as the sub-module.
  • To aid development even more, GraphiQL is also included at /graphql/explorer, which acts as a user interface for you.
  • Lastly, there are built-in debugging tools that are competent to issue queries and analyse their responses and that too in real time.

GraphQL is a powerful tool and Drupal has ensured that all its community can easily tap into its power.

The GraphQL Twig module is the next advancement in Drupal. It was and generally is thought that GraphQL queries can only be sent over HTTP, but that isn't true. It can be, but there are other ways as well and this module personifies that. You can segregate the Twig templates from the internal structures of Drupal, so that maintenance and reuse is easier without any involvement of HTTP.

Should we use GraphQL or JSON:API or REST in Drupal?

Before getting into why GraphQL, we have to understand why not REST and what are its limitations. First of all, REST UI is absolutely important to set up the REST module in Drupal. Not to forget, it can be pretty arduous to configure it. In addition, the primary problem with REST is that it over fetches information, bombarding you with data you do not even need and certainly did not ask for. You might have just needed the title of an article, but the author’s user id is also included in the response list. This leads to a cycle of follow-up queries and you end up with the article’s title, link, its author’s name, his information and the entire content of the said article. Over-fetching is putting it lightly.

Because GraphQL uses the APIs in a more simplistic way, it becomes better than REST endpoints. The former does not expose single resources with fixed data structures and links between them, rather it provides you the opportunity to request any selection of data that you may need. You can easily query multiple resources on the server side simultaneously, consequently combining the different pieces of data in one single query. Hence, your work as a front-end developer becomes as easy as pie. You could still go for REST, if you wanted, it does have its own set of merits

Now coming to choosing between JSON: API and GraphQL, this is a more difficult choice to make. These two perform at a level parallel to each other. For instance, installing the JSON: API module is a piece of cake with absolutely no configuration required. As for GraphQL, the installation is easy as well, but there is a need for some configuration. Do you see why I said the choice was difficult?

Where decoupling is concerned, JSON: API and GraphQL are much better than REST. Server-side configuration is not required by the clients to perform content queries. While JSON: API has the default setting of altering every client-generated query, GraphQL mandates the permissions to be held by the consumer so that he can forego any access restrictions. There is no right or wrong method here, both have the right filtering tools for decoupling and both are security for your content.

When is the GraphQL module the most suitable?

Only fetching the data that is asked for should be the tagline of GraphQL and that is why in scenarios where you need data retrieval, it becomes quite handy.

  • Decoupled Drupal applications, with Drupal as the content repository and a React, Angular or Ember powered front-end.
  • Mobile applications, wherein data storage is the need of the hour.
  • Internet of Things data storage.
  • If you want to retrieve the JSON data from Drupal.
  • And also if you plan to use the Twig Templates in Drupal themes.

The GraphQL module would be perfect in all of these instances.

Why do GraphQL and Drupal fit so well?

GraphQL is considered to be an excellent fit for Decoupled Drupal websites, especially if they comprise entities as fields for stored data and these fields have relationships with other entities. GraphQL helps you curate queries for just the fields you need from the Article. This kind of flexibility makes it easy to restructure an object you wanted back, helping you to change the display as well. You can write queries, add or remove fields from the results and you can do all of this without writing a code on the backend.  The GraphQL module’s ability to expose every entity including pages, users and customer data makes all of this seem quite simple. So, it would be suffice to say that the decoupling experience would not be the same without GraphQL.

Has GraphQL impacted the conventional server-client relationship?

Traditionally, the server was the dominant in the server-client relationship, however, now the client holds more power and GraphQL has made certain of this. With it, the client need not follow everything the server imposes, it can simply enunciate its needs on a per-request basis. After the server would show the data possibilities it is equipped to fulfil, it would be extremely easy for the client to define its needs with the catalogued possibilities at the forefront. The shape of the values GraphQL API inserts and returns is every bit the same.

On top of these, GraphQL taps into the deeply nested relational data structures, which are suitable for graph models. The abilities of GraphQL schema and query validation ensures that it can prevent distributed denial-of-service attacks, thereby preventing attempts at overloading queries. The benefits of GraphQL in Drupal are indeed far and many.

What Will the Future Look Like?

GraphQL is not a part of Drupal Core, being an advanced tool that is a little more complex to use. The future is not showing any signs of it becoming one either. However, there are other aspects to look forward to. GraphQL v4 for Drupal is one of the most awaited releases of the GraphQL module. It would bring along numerous improvements for the module that seems to be perpetually evolving. GraphQL schema will be in total control of Drupal developers, since schema customisation was the holy grail of this module, things are looking up and the future brighter. GraphQL and Drupal have a long way to go.

Nov 11 2020
Nov 11

Drupal development is not everyone’s cup of tea, however, it could be, provided that the person at the development end has the right skill set to handle all of Drupal’s potential. With Decoupled Drupal the need for these skills becomes even more prominent, you have to have excellent front-end and back-end developers separately since the two are independent of each other. And this is where the hiring process of the right set of professionals for your Decoupled Drupal projects becomes tricky and cumbersome.There are a lot of aspects to take under consideration and a lot of different skills to look for.

To make your job a tad bit easy, here is the checklist of the skill sets and the professionals that you need to successfully deliver the Decoupled Drupal projects.. 

What skills are needed for Drupal development during the decoupling process?

When you decouple Drupal, you are only going to be using it as a content repository, meaning it would only serve a purpose for backend development needs. Even if you use it for back-end, you are still going to be using it, so you would need good Drupal developers. So, here are the skills you need to be looking out for.

There four game pieces denoting the four members of the Decoupled Drupal team.

Proficiency in Site Building 

You must know how important it is to attend primary school, the things we learn set the pace for our entire educational journey. So, what primary school is to us, Site Building is to Drupal. It is the most basic need of a Drupal website. 

The primary purpose of a site builder is to reap all the benefits of Drupal by making it run and configuring all the options required to make a website fully functional. There isn’t a need for a custom code for this to happen, rather the Admin User Interface is equipped to handle it on its own. There are several other responsibilities of site builders as well, so, when hiring a site builder, you must keep in mind all of these.

  • Installing  Drupal manually and also doing the same with an application or a service;
  • Downloading and installing modules along with disabling, uninstalling and removing them;
  • Understanding of all core and contributed modules; 
  • Thorough knowledge of fields and entities with expertise in content and non-content fields;
  • Finally, being familiar with blocks, menus and navigation as well as the basic Views skills;

All of these are the everyday requirements for site builders, and a proficient one excels at all of them.

Proficiency in Backend Development

The decoupled Drupal requires backend developers to be at their best at all times. This is because an impeccable front-end would seem sub-standard, if the content repository is not up to the par. There when hiring backend developers, you have to be extra picky and choose one who fits the criteria to the T. And here is what the criteria looks like;

  • Unlike site builders, Backend developers are involved in writing the code in PHP and other languages, so they must have experience in PHP and MySQL at least. 
  • They must be competent in creating and executing modules. The added knowledge of building custom modules in Drupal 7, 8 and 9 (for Drupal 7 and Drupal 8 have not reached End-of-life as yet) is always preferable. 
  • They also need to have advanced knowledge of themes, consuming web services and automated deployments to name a few. 
  • The backend developer has to be aware of all the security concerns as well, along with the ways of overcoming them.

Proficiency in Theming

Theming is a part of Drupal’s front-end development. I know you must be wondering why decoupled Drupal would need front-end developers with experience in Drupal. To answer your question, I have three words; Progressively Decoupled Drupal

Because the entire front-end is not separated from Drupal, it is important to have a good themer to build around Drupal’s front-end capabilities. Themers are responsible for the front-end design as well as the development and implementation of the client-side architecture. 

For this purpose, 

  • they need to be experts in front-end technologies;
  • they need to be experts in installing themes and generating sub-themes using PHP or Twig in Drupal;
  • they need to be experts in designs and modifying them into a completely functional issue;
  • they need to be experts in creating such modules that would expose the configuration to the site builders. 

When you find someone like this, you would have the perfect themer for your progressively decoupled Drupal. 

Read these infinity stones of Drupal development to adhere to the best practices when it comes to everything ranging from site-building to backend development.

Proficiency in Drupal Architecture 

Drupal work is often regarded as web projects, and each project has to have someone who is aware of the ins and outs of the work. And in the case of Drupal that person is a Drupal Architect. 

A Drupal architect is essentially the manager of the project, who possesses knowledge of all the key areas of the project. From backend development and site building to front end development and theming, he needs to be proficient in every task as a leader. 

He should have an in-depth understanding of the ways to optimise Drupal because that is what the main role of a Drupal architect is. For the same, a certain level of expertise in PHP, MySQL, JQuery and CSS along with the knowledge of implementation tools like Varnish, GeoIP and UberCart comes in quite handy. 

Note: Some proficiency in front-end technologies is always beneficial for Drupal developers. This may seem odd to you, since we are talking about the Drupal skills in decoupling. However, it isn’t much of an oddity and let me tell you why. We know that when decoupling is done, the presentation layer is entirely separated from the content aspect of a website, yet they still have to work together and they have to be in sync. This would become all the more convenient for decoupled Drupal developers, if they have some knowledge of the current front-end technologies. HTML, CSS, React and Gatsby are some of the most used technologies, so an understanding or maybe even some experience in using it would come in very handy for the streamlined development of a decoupled Drupal website. 

Read these infinity stones of Drupal development to adhere to the best practices when it comes to everything ranging from site-building to backend development.

What is the requirement for Drupal web services?

The decoupled Drupal needs a good API layer for it to give you all the benefits it boasts. And a good API is only good when it is being handled by competent hands and these hands are your developers’. 

There are three particular web services that are being implemented during decoupling. Although all three will be achieving the same goal, the way they do it is quite different. Therefore, your developers need to be aware of even the minutest details of these web services, especially with respect to the different Drupal versions.

The logos of GraphQL, JSON and REST are displayed horizontally.

Starting with GraphQL, firstly, it is not available in Drupal 7; an expert developer would know this. The GraphQL module in Drupal 8 and 9 will let your developers create their own custom schema or extend an existing one, as long as they are good with coding. 

JSON:API is also not available in Drupal 7 and even in Drupal 8, it was a late addition, having been added as a stable core feature in Drupal 8.7. With the JSON:API module, a developer can decide which HTTP methods he should be using along with which response codes should be returned and when, eventually increasing productivity. A JSON:API expert would do it with ease. 

Coming to REST API, it has been a part of Drupal core for a long time. Your developers need to be equipped to configure REST resources, customise their formats, customise their authentication mechanism as well as create the plugins.

A developer who speaks fluently in Drupal web services is the developer with the right skill set for Decoupled Drupal, since the API is the thread that holds both the front and backend together. 

How do you capitalise the separated front end?

Now that Drupal specific skills are out of the way, let us move on to the presentation layer and the technologies the front-end developers need to be experienced with. 


When talking about front-end development, the first things that come to mind are HTML and CSS. As you may know, the structure and layout of a page, both of the visual and aural, depends on these two, making them quite crucial for your web pages. Henceforth, they are the  foundational technologies for building web pages, front-end developers need to be experts in these. 

JavaScript Frameworks

For many, the primary reason behind taking up decoupling is to take advantage of the advanced JavaScript framework. Although Drupal has its own JavaScript library, it still lacks in the features provided by the JS framework.

React, Vue and Angular tend to be the most sought after technologies for transitioning into decoupled Drupal., with Vue.js being the latest addition in the mix. Frontend developers need to be aware of these and get the most of them with their knowledge. 

Static Site Generators 

If you have a static site with already available input files, you would want to delve into Static Site Generators for your frontend development. For this reason, you would need experts in SSG to fully capitalise its various tools. Gatsby, Metalsmith and Tome are the ones that are the most renowned at present. 

Note: There is one more thing that you should be looking for in your front-end developer and that is the knowledge of Drupal. Like I mentioned in the previous section, the Drupal developers need to have some knowledge of the front-end technologies, similarly, the front-end developers need to have knowledge of the Drupal. Both the back-end and front-end may be different and their development may also be different, but they are going to be a part of one web project, so both teams need to have some cognisance of the other’s working. Decoupling would make a lot more sense then.

What other skills should you be looking for?

Up until now, we have discussed all the skills specific to the development of decoupled Drupal, you might think that your work is done, but it isn’t. There are certain skills that need to be held by developers, whether they are involved in decoupled Drupal or monolithic Drupal and they are going to be equally important for your decoupled Drupal project. 

Adept at Designing

The process of website building starts with designing. The very first step towards development is the making of wireframe, which is basically a design template. This wireframe sets the pace and the direction of the web project, so your designer has to know what he is doing because if he doesn’t, the end would not be as enlightening as you might want. 

Designing mandates tools, without them a designer would be helpless. Sketch, Figma, InvisionApp and Adobe XD are some of the go-to options for User Interface designing. The apprehension of these would make a designer adept at his job.

Adept at DevOps 

In essence, DevOps is an IT service delivery channel that focuses on the adoption of practises that would collaborate your operations with the development team. For this to happen, you need a DevOps Engineer or a System Admin, who would be responsible for deploying websites to the live server. 

  • Expertise in Linux;
  • Expertise in bash scripting and continuous integration;
  • Expertise in automations technologies;
  • And expertise in IAC (Infrastructure as Code) are essentials for this particular hiring objective. 

Adept at QA 

QA refers to quality assurance. It is a position held by developers to check the quality of work being churned out. They act as the targeted client and see whether what they are getting from the website is up to the standards or not. 

Someone with limited knowledge of Drupal, web technologies and the industry requirements would not be a good fit. You would only be able to check something, if you know what to look for, right?

Adept at Project management 

Like the suggests, this is a skill that oversees the project from the very beginning to the very end. From time deadlines to the day-to-day progress of the project, each and every aspect has to be monitored. 

Drupal Project Management requires the manager to be skilled at a variety of things, namely;

  • Expertise in team management and segregation of workload;
  • Expertise in dealing with the clientele to understand their requirements and acting as the middle ground between them and the team;
  • Expertise in analysing and rectifying plausible risks during the project;
  • Expertise in the Drupal and all the technologies that accompany Drupal projects; 
  • And expertise in using reporting tools and implementing sound SEO strategies.

Adept at Business analysis

Every Drupal site has a business side, so when hiring the right skill set for decoupling, business analysis holds a key to success. Through business analysis, the business and IT sides of the website find a connection and work together. This is done through the use of data analytics, which help in examining the undergoing processes, analysing its needs and effectively communicating the same to the executives and stakeholders along with running logic/system interference with them. 

While using Drupal, it is always preferable to have an analyst that has a development background with knowledge of Drupal. Extroverts are usually ideal for this position, since communication is vital here.

The Sum Total 

Drupal is a pretty diverse system and an even higher level of diversity is found when Drupal is decoupled. Since you would be trying to capitalise Drupal in addition to capitalising other frontend technologies, you would have to put in an extra effort in the hiring process. Decoupled Drupal developers need to be equipped to handle the diversity it is going to inundate them with. The right skill set would help you and them to reap the benefits of decoupling. 

Nov 06 2020
Nov 06

Drupal is amongst the top ranking CMSs in the world, its capabilities, both on the front-end and the back-end has made it one of the very best. Yet there were many who thought Drupal lacked somewhere, especially in harnessing the hottest technologies available. And Drupal had the answer to it with Decoupled Drupal

Decoupled Drupal has generated a lot of buzz around it, making it almost ubiquitous in the industry. The full separation of the structure from the content has aided the content management systems with appropriate means to accelerate the pace of innovation and this is the primary reason for Decoupled Drupal to gain an edge over its competitors.

If you are reading this blog, you might have some knowledge about decoupling or the buzz around it might have pulled you in and now you want to try and see whether it is suitable for you or not. Before we get into that, let me give you a clearer picture of what Decoupled Drupal actually is, even if you have some idea of what it is. So, this blog is going to accentuate all the aspects of Decoupled Drupal to help you understand whether it indeed is the right choice for you or not.

What is Decoupled Drupal?

Traditionally, websites operated in a similar fashion to a magazine, meaning they provided static communication to the users, wherein the user is only a witness and not a participant. This system worked for a long time, but no more. Today, websites excel because they are interactive and not just one platform, but many. Phone applications, social media and the answering of client questions through chatbots, all of these have altered the audience’s expectation of websites and consequently the web builders are trying to find ways to improve their user’s experience. 

Drupal, even in the conventional sense, was equipped to handle multiple channels. A Drupal website can be accessed through multiple devices, be it computers, tablets or smartphones. This speaks for Drupal’s versatility and its flexibility, which is why it became so popular. The monolithic Drupal with its ability to store content, present it to the user and create an editorial interface makes it proficient enough to run websites, yet people want more. Since flexibility is the equivalent of Drupal’s middle name, it provides yet again. Get a complete outlook on differences between monolithic and decoupled Drupal architectures here.

In simple terms, the Decoupled Drupal gives room to new technologies on your website, so that they can also work their magic on them. With decoupling, you will be able to segregate your front-end from the back-end and use React and node.js for the former, while the latter would be managed by Drupal. So basically, you will have the best of both worlds, the excellence of Drupal and the many front-end technologies available in the market.

Let us look at some of the technical aspects of Drupal to get a better understanding of decoupling. 

  • The display management is generally handled by JavaScript frameworks and Static Site Generator when decoupled as opposed to Drupal managing it.
  • The speed and performance of Decoupled Drupal sites is usually seen to be higher than the monolithic Drupal sites. 
  • The technical stack in Decoupled Drupal is usually seen to be quite complex.
  • The workflow from the front-end to the back-end is loosely connected, but the connection never falters.
  • The editors enjoy full control over the content, however, additional effort may be required to preview the content.
  • The RESTful web services have allowed Drupal 8 to become an API-first back-end serving web applications, which is absolutely necessary in decoupling.

To get a complete picture of different options of decoupling Drupal, read here.

Why Should You Decouple?

You would only be willing to try something, if you know that you are going to benefit from the trial. Am I right? The same is true for Decoupled Drupal, it has only been able to gain traction in the industry because it is advantageous to the developers. It is these advantages that become the reasoning behind implementing Decoupled Drupal architecture

Yes, it builds creative websites that have independent components making development easy and smooth. A front-end developer would not have to be reliant on a back-end developer to make a change in his presentation layer, nor would a backend developer have to worry about the impact of his changes on the presentation layer. So, can this be the only reason to take on the Decoupled approach?

Decoupled Drupal brings along several advantages that are single-handedly responsible for its adoption. Let us shine some light on these.

A green check is on the right, with the left side covering the reasons for choosing decoupled Drupal.

Impeccable Performance 

The foremost reason as to why decoupling should be taken up is because it enhances your performance more than you could have thought. The separation of concerns means less request time and that consequently makes your website respond faster and performance automatically enhances. 

Another reason for elevated performance is JavaScript. JS frameworks are known to be multi-thread and asynchronous, what this means is that it is fast. There would be performance issues that would mandate your attention, but even those become easier to tackle. Therefore, a JavaScript front-end is faster as compared to a Drupal front-end. And this is why decoupling is being sought.

Impeccable Development 

With the risk of repeating myself, I am still going to say that when you decouple, you create a clear cut separation between the front-end and back-end. This can be interpreted to mean that both the front-end and the back-end can develop at their own pace without thinking about the effects of the same on the other. They work in parallel. As long as a sound API is in place, development won’t be blocking work since the work is being done independently. 

And there is also the fact that the risk of re-platforming becomes almost non-existent with decoupled Drupal developments.

Apart from this, the 'decoupling team' is usually bigger than a 'monolithic team'. As the saying goes, the more the merrier; the higher number of developers means more ideas for development and faster development. A five-man team is going to bring more results than a one-man team. Do you agree?

Impeccable Publishing and Multiple Consumers

Decoupling comes with an omnichannel presence and the ability to support multiple consumers. Let us understand how.

The Decoupled Drupal architecture works around the API-first notion, which basically means that all your consumers are on a leveled field. This makes publishing all the more easy. You can create content for your website and with just a few clicks, it could be published on multifarious platforms, including social media, intranet and your microsites. Your content would be reused in many different ways and many different times. Since the content is not rigid to the current form of your website, you would also be able to reuse the same after a total website redesign or two.

The Decoupled Drupal is not only the driving force behind your website, but also all the other apps you have, be it on smartphones, set-top TV boxes or maybe the gaming consoles.

Impeccable Team Management 

Decoupled Drupal may mandate a larger team, but it, in fact, makes the working of the larger team smooth and result oriented. You could have 50 developers on your team, yet there won’t be any overlapping concerns. Why? Because decoupling clearly segregates the duties of all developers.

Apart from team management, it is also quite easy to create a team. You may very well know that there is a dearth of Drupal specialists in the market, however, developers proficient in JS are in abundance, for lack of a better word. This makes the process of creating a highly competent team easy, since you do not have to find developers who are skilled at every aspect of website development. 

Impeccable Innovations 

Decoupling and the latest technology go hand in hand, and you must know that the latest technology means more innovations. Decoupled Drupal architecture can aid you in implementing frameworks that are top-of-the-line. Be it Angular.js, Backbone.js, Meteor.js, Node.js, or Ember.js, you can work with any of these. 

    For creating UIs, you can take up the React library;
    For tracking state, you can take up Redux;
    For mobile applications, you can take up Google’s AMP or Polymer tools.

Using all of these would only accelerate your innovative streaks and make your web applications as innovative as it can be. Learn more on how marketers can extract the power of decoupled Drupal here.

When Should You Decouple?

By now we have established enough facts that Decoupled Drupal is a package full of advantages. Now, it’s time to delve deeper and seek the accuracy of circumstances in which it can be put into effect. 

The situations to choose decoupled Drupal are mentioned in the top half and the bottom half has two puzzle pieces denoting separation of the front and backend.

When your back-end and front-end needs are separate 

Decoupled Drupal, by definition, states the separation of the front and backend, so if you feel the need to separate them, then why not? Having a modern JavaScript packed front-end by using React or Angular and the very proficient Drupal backend is a combination that would only bring benefits. All the abilities of JS frameworks are not yet available in Drupal and decoupling can help you capitalise them.

When you have the right team

Having a need for decoupling is not going to cut it for you, you also need to have a skilled team to execute the process of decoupling Drupal. The decoupled approach divides your team into two subdivisions along with your project. Each subdivision would be responsible for a separate codebase, which would later become a complete tech stack. These teams would have to work in sync, although parallely to make the project a success. Provided that you have the team, which has all the varying skills and experience required for the decoupled project, you can and should take on decoupling.

When you have clearly defined data roles 

For decoupling, you must also be in tune with your data needs. Since Drupal would only act as a content repository in the Decoupled approach, it becomes essential for you to remember the communication lines. In this architecture, you will end up using other data services. Such a situation demands clarity, you should be clear as to how you want the data interaction to the front-end, do you want it directly through the service or through Drupal’s API.

When you can support new architecture

Moving towards a decoupled approach means you would need to evaluate your hosting provider. The architecture post decoupling should be under its handling capabilities and that needs to evaluated beforehand. From security measures to additional caching, the host should be able to handle a non-Drupal front-end. If not, check how long your contract is and work from there.

When you have to cater to different channels

The concept of write once and publish everywhere has become synonymous with Decoupled Drupal. The ability to cater to various publishing platforms comes with ease through decoupling. So, if you have a single application that is supposed to dispense content onto various channels, decoupling is going to be great for you. Although it would take some editorial control away from you, the fact that your control will be reused, without much effort from your part makes up for it.

When metadata holds prominence 

Metadata is often considered to be a part of the page content, it encompasses the microdata such as ad targeting, meta tags and JSON LD. When content is shared on multiple platforms, the metadata becomes a prominent part of the back-end, as opposed to the front-end. So, metadata would only be shared on different publishing platforms when it is decoupled, similar to the typical content. 

When redirects are not essential 

The redirect logic only adds complexity to the decoupled architecture. So, it would only be prudent for you to decouple when you do not need control over the redirects and your architecture will support multiple redirects rules being combined as one.

When Drupal is bringing in more work 

Drupal can be as easy to use as it can become a hassle, this depends on your perception of it. For many, Drupal seems to bring in more work than not. The many built-in features are the cause of it. The node edits, tabs and screens, you would not use all of them, so they just add to your workload because you would always be working around them. 

The simple example of evites would help you understand this better. The content structure would be easy to build, however, creating the evite, its customisation along with the addition of the recipient, preview and actually sending it is a whole other ball game. In such a scenario, decoupling helps ease the work.

When you have a static menu

The traditional Drupal can effectively manage your menu lists, while doing the same in the Decoupled Drupal can become tricky. It is always preferable to avoid complexities as much as possible, so if your site has a static menu, which can be created in the front-end application, decoupled Drupal would suit you to the T.

If you and your web applications are aligning with the aforementioned scenarios, then decoupling can be beneficial for you. If not, well you are intelligent enough to answer that. 

When Not to Decouple?

Decoupled Drupal architecture indeed paints a prettier picture that is more than appealing. After reading up till now, you might have made up your mind to take on the Decoupled approach and part with the coupled Drupal and you might even be right. The decoupled Drupal could be the right choice for you, but you cannot be totally sure of that without taking into consideration the challenges it is going to dredge up for you and your site. Have a look at these first and then decide for yourself. 

The instances to avoid decoupled Drupal are written on top of a big-green cross.

When you do not want to increase costs 

The foremost consideration when deciding on a project has to be its financial implications. Whether your pocket allows you to take it on is one of the most crucial questions to ask. Although Drupal is open source, requiring little to no costs of implementation, Decoupled Drupal is a whole other ball game, since you will be building a front-end that is entirely or partially independent of Drupal. And this is the reason why decoupling becomes the opposite of cost-effective. 

  • Features that would have been free would need to be built from scratch by your developers like Website Preview and this costs money.
  • The creation of a sitemap is often done by using a third party XML sitemap application, developing it on your own would cost so much more.
  • The creation of a good API that would aid in future developments rather than constrain them costs more money.
  • The decoupling team also becomes an expensive affair since more number of developers need to be hired.

Overall, the Decoupled Drupal requires massive infrastructural investments simply because you will be losing a high degree of Drupal’s out-of-the-box functionality. So, the question comes again, can you afford it?

When you do not want to increase complexity 

Decoupled Drupal comes with a 180° change and this change mandates another 180° change in the mindset of the developers and the content authors. It would be suffice to say that it becomes complex. The simple fact that editors would not be creating pages, but reusable content that is well-structured can become a lot to digest. 

On top of this, the infrastructure becomes cumbersome and complex as well. The simplest of tasks like previewing content before publishing it is no longer an option that is available. Since the content is to be posted on multifarious platforms, the task would be meaningless anyway. 
You would also need to be extra vigilant about the coding, if the front-end logic is encoded in the API, the recipe is going to burn your tastebuds. 

Taking on the complexity of Decoupled Drupal would only turn out to be prudent, when you have multiple sites and multiple consumers. 

When you do not want to lose page control 

Control is another thing you part with along with Drupal’s out-of-the-box functionality. If you think that, as an editor, you will have free reins over the placement of your content on the page, then you, my friend, are mistaken. Editors have non-existent control over the presentation of their content, the URL included. And if you want to have the control, it can be done by certain tools. However, the process to get it done would be extremely complex.

When you do not want a web of systems

When you decouple, you don’t just do it for an app or a site. So, when you decouple, there is a high likelihood that your team is going to build much more than a website and a JS app, rather a web of systems. These networks require a lot of build and testing mechanisms and that adds to the complexity of Decoupled Drupal. Then, there is the issue of human intervention. There are many decoupled sites that manually integrate the API, which becomes a hassle when the number of clients is on the higher side.

Continuing on the point of complexity, Decoupled Drupal creates a web of systems. It would seem to work until you have to debug. Once that point comes, the web of systems turns into a nightmare because you do not know where to look. Fixing a broken link in a web is far more difficult, since you can’t be sure whether the problem lies in the API or the request.

The Right Choice 

Yes, Decoupled Drupal demands a lot of work and it is as costly as it is time-consuming, however, its benefits easily trump all the drawbacks. 

Yes, Decoupled Drupal is going to increase your costs initially, but in the long run, it would reduce your overall development costs.

Yes, Decoupled Drupal would require a lot of getting used to, but once you are used to it, you will only reap the benefits of the JavaScript powered front-end. 

I would say that Decoupled Drupal is always going to be the right choice as long as you know that you can and will overcome its drawbacks. Regardless, if you believe that your current monolithic Drupal is too good to part with and it is accomplishing all your goals, you might have to re-think the decision of decoupling. It would only serve you its benefits, when you actually have a need for it. These success stories on Decoupled Drupal would give you a glimpse of your future project and its success. So, what will your choice be?

Nov 02 2020
Nov 02

Configuration management is an increasingly important foundation in the technology world that is supposed to solve all the woes faced by modern Content Management Systems (CMS). Be it Drupal or any other CMS, configuration management has made things easier than ever before and has positively impacted business and its related activities. There is no denying the fact that configuration management is important for any business as the term configuration is what makes your system work. 

With the increase in the number of Drupal 9 installations, there is a simultaneous increase in the number of burning questions on Drupal 9 that have sprung up. One of the key questions is around Drupal 9 configuration management strategies. However, configuration management in Drupal 9 is not as easy as upgrading to Drupal 9.

Therefore, if you are here to know what it takes to implement Drupal 9 configuration management strategies, then you are in luck! In this blog, we will be giving a detailed insight into Drupal 9 management strategies, followed by the factors to drive the same. But before we start, let’s take a step back and understand what configuration management actually is all about in Drupal. 

Configuration Management: An overview

To begin with, configuration management is a form of IT service management that is held responsible to establish and maintain the consistency of a product's performance, functional, and physical attributes with regards to the requirements, design, and operational information throughout its lifecycle. The prime objective of configuration management is to make sure that you can review, test, and predictably deploy all configuration changes to production environments.  

The configuration is the collection of admin settings that determine how the site functions, as opposed to the content of the site which is typically captured and deployed through YAML files. In Drupal, site configuration data is stored in a consistent manner which typically includes everything, right from the list of enabled modules to content types, taxonomy vocabularies, fields, and views. Configuration management has come a long way in the Drupal world. In other words,  the former has undergone necessary changes and has transformed a lot from what it was in Drupal 7 and Drupal 8. 

In Drupal 7, both configuration and content were kept safe in the database. As a result, contributed modules like Features were assigned the task of moving configuration to other environments. Drupal 7 configuration was going well, however, the configuration wasn’t effortless as it could be which eventually led to the change in configuration management in the later version i.e. Drupal 8.

Drupal 8 being the latest configuration improvement after Drupal 7, was able to deliver better and faster configuration management. In Drupal 8 Core, configuration for most site settings as well as for the definition of structural pieces can be exported easily with one click of a button or a single drush command. Further, you were allowed to commit and merge configuration changes in source code control, deploy the configuration, and then import it into the destination environment. Having a configuration management roadmap also helped with improvements made in Drupal 8 releases. For instance, the support for creating new sites from existing configuration was included in Drupal 8.6.

Configuration management strategies in Drupal 9

Drupal 9 configuration management is a bit rough process that comes along with some problems to wrestle with. In other words, there are some significant challenges in the pathway of Drupal 9 configuration management that do require some additional strategy or planning to better understand how you will utilize the configuration management system. Some common configuration strategies include the following-

1.  Apply Complete Config Sync:


  • all configuration is transferred into a configuration sync directory 
  • config split and config ignore enhances the core config system
  • drush manages config imports/exports
  • ideal automated config imports during deployments
  • config imports should occur following database updates

Appropriate for both site and profile config splits, this strategy can work wonders when you have a common set of configurations (90% or greater) that is shared across all splits and further deploys the split and/or config ignore to handle specific cases wherever necessary. Not to mention, this strategy can go wrong if you have a large platform and each profile/site has a large quantity of unique/bespoke configuration. 

2.  Apply Partial Config Sync:


  • config is kept in module/profile/theme config directories and installed only when the respective parent container is installed
  • database updates and drush make the necessary updates to config 
  • contributed modules such as config split/config ignore are generally not required 

Regardless of being flexible in nature, this strategy often ends up with multisite platforms which are almost impossible to update owing to the unintended consequences of changes and development. Moreover, unlike the monolithic approach, the partial approach does not have paradigms that can help you keep troubles at bay. As a result, this strategy puts you in a predicament which is certainly difficult to get rid of. 

Factors to consider while formulating a strategy

One of the biggest mistakes that any developer can make is to start planning without considering the best factors. Sounds bizarre? Well, this happens for real. It has been observed that most of the Drupal-based sites value the end-product more than what they have on their plate because of which the development team leads to failure. 
As a matter of fact, creating the product breakdown structure i.e. pre-considering the necessary factors can help you deliver the end product in the most efficient manner. There are three key factors that are of supreme importance and required to be considered.

Differentiate between a single site, multisite and many sites

Configuration management strategies in Drupal 9 are highly driven by the architectural considerations and decisions that cannot be overlooked.   

  • Single Sites: It includes one single site running a single codebase, database, and file system.
  • Multisites: It includes sites with a single codebase but separate databases and file systems.
  • Many Sites: It includes sites with separate codebases, databases, and file systems that still somehow derive from a templated/distributed codebase.

Note: While a single site may consume the configuration stored in their codebases entirely, multisites and many sites are much less straightforward and have at least some varied config.

Find variation in features

Next in the row is feature variation which focuses on the commonality of features that you provide on your platform. 

For example- you are building a multisite codebase where your customers want to have a hero carousel but have clashes relating to the hero banner. One of the customers demands a horizontally scrolling carousel with a background image and call to action. On the contrary, another customer demands a vertically scrolling carousel with a background video. In such a scenario, a common feature is a carousel that needs to be taken into consideration while creating a configuration management strategy. There are two ways to perform this- 

  • Build two hero carousels that offer the same things with little or variation.
  • Build one hero carousel that offers a few extra fields to allow changing the scroll direction, background type, etc.

Group the identified features 

Once you have successfully identified the features, it’s time for you to invest some time in grouping these features. Generally feature grouping falls under four major categories.  

  • All Drupal sites share the same config 
  • Sites are categorized into profiles/distributions. Further sites within these groups share the same config 
  • Regardless of the fact that each site requires individual configuration, they still share the majority of their config 
  • Each site possesses bespoke configuration and is entirely unique in nature.

Tools of the trade

When it comes to Drupal 9, formulating a configuration management strategy won’t suffice. That is to say, you might need to arm yourself with some key modules/approaches that can help you sail through the complex Drupal process. In a separate blog, we listed down the must-have modules to start your Drupal 9 project. Here, we will throw light on some Drupal 9 modules that will help strengthen your configuration management strategies. Let’s have a look at them. 

Configuration Split Module

The config split module enables you to define sets of configurations that are required to be exported to separate directories when exporting and get merged together when importing. Further, you can also define in settings.php which of these aforesaid sets should remain active and further consider for the export and import.

Configuration Ignore Module

The config ignore module is basically a tool that helps you keep the configuration you want, in place. If you would like the system.site configuration (including the site name, slogan, email, etc.) to remain untouched, on your live site, no matter what the configuration in the config folder is, then this module is what you are looking for. Also, this module is the best way to save yourself from the grueling devel settings that change every time you import configuration.

“Installed” Configuration 

Tied up with a module/theme/profile, this config is installed when that thing is installed. Not to mention, the feature module uses the same approach that the installed config uses. 


To conclude, we hope this article has summed up everything that you have been looking for. While Drupal 9 configuration management is still a complex process, it is indeed a great step forward in a world that constantly undergoes technological shifts. Further, configuration management in Drupal 9 requires a team of professionals that are proficient enough to understand how configuration management works, what is it capable of, where its shortcomings are, and how to merge and resolve conflict. 

Want to learn more about Drupal 9 configuration management? Contact us at [email protected] and our industry experts will help you spot and resolve the issues encountered at the strategy stage.

Oct 30 2020
Oct 30

Code reviews help in identifying bugs before the testing phase. Many people skip this step and think of it as an ongoing practice during the development stage but code reviews have proven to be a great assurance strategy. Getting your work reviewed and reviewing other people’s work is an excellent way to learn and grow. 

A collaborative environment among different teams is the need of the hour. Today, when things have gone digital, collaboration and communication gaps need to be given more importance to keep the workflow consistent. 

A happy and smooth collaboration between the designers and developers is important but is a little difficult. The idea of someone else reviewing your work might sound scary. For a designer, having someone not as creative review their work is like a threat to their creativity. And likewise, for a developer, getting their codes and programs reviewed by a designer is not easy to take. But if you think of it as many ideas coming from different sources and collaborating together to make something bigger and better, it will be easier for you to let other people look into your work.

So how do we get the two teams to get along? We will get to it, but first, let’s look at why and how code review is important.

Why do a code review? 

When you have someone who reviews your work, and also when you know someone is going to review your work, helps in increasing the quality of your code and makes it an error-free one. According to The 2018 State of Code Review by SmartBear, 73% of people said that code review helps share knowledge across their team and 53% said that code reviews help in mentoring less experienced developers.

Code review plays an important role in building a collaborative culture among the team members. When more than one person is involved in a code review process, it should not just be 'my code' or 'your code', it should become 'our code'.

A few principles that need consideration are as follows: 

  • Face to face discussions.
  • Feedbacks should be given for the work and not the author.
  • Never forget to praise the good.
  • Suggest, Don’t command.

These principles, if followed, make code review a positive force instead of a negative and disappointing one. The teams must allow each other to ask questions and clear their doubts without any hesitation and keep motivating each other to build something great together.

If doing a review holds such advantages, why only do it for code?

For a business to run efficiently, the design and development teams need to come together. And to truly maximize the outcomes, the teams should be able to work as teams. Collaboration, communication, and consistency have to be a part of the process. If this is not done, you will have to deal with frustrated team members, unhappy clients, lengthy rants, many missed deadlines, and whatnot. To stop such things from happening, let’s look at these steps that will help in strengthening the collaboration between designers and developers. Learn more about the importance of code review here.

Steps to consider for the designers for the code review process

a staircase in blue amidst black background to explain the collaboration between designers and developers during code review

Kickoff calls

It’s important to understand your client’s requirements, but along with that, it is also important for the team to understand every little detail of the project.

Before starting any review, all of the team members should make sure that they are on the same page and are clear about the objectives and the details of the project. To ensure this, start every project with a kickoff call. This will clear any doubt or concerns before starting the review. 

All the phases of the project should be organized in a way that is understandable by everyone.

Information sharing

You might have someone to research or look for little details around the project, but this is an important step that needs both designers and developers to research, as it lays the groundwork for all the decisions that are made for the project later during the review. Everyone involved should have information beforehand about the project. 

The developer should be made aware of the initial plans so that if any of the ideas cross the limitations of the project, they can be removed before initiating the review. Remember, finding defects before launching is what we need to do. And also, verify that those defects are fixed, not just found. Once you have sorted them out, you can start driving meaningful process improvements. 


This is the phase where the designer works alone. Here the designer needs to work on the components that have already been approved by the developer. This will make sure that there is a consistent pattern and the basic elements hold on to the best practices. 

This helps the designer to focus on the designing part and create the best user experience. There is nothing for them to worry about building anything from the base. 


Once the designer is done with the designing part, the project needs to be pushed for feedback. Instead of sending screenshots of the project, it's better to send a functioning version that the reviewers can interact with.

In this phase, the developer needs to be a part of the review process too. So, in case there is an issue about how a design will be implemented, the developer can sort it out before development starts.

The Handoff 

After the review of the prototype is done, you have successfully cleared the first step that decreases the gap between designers and developers. This step involves testing each other's work for both designers and developers. There are many tools out there that do the work for them, such as, Sketch, InVision, and Unite UX.

The designers have to layout the design specifications, that include:

  • Font size and styles
  • UI functionality
  • Typography
  • HEX codes
  • User flows
  • Row and column layouts
  • Spacing


With the help of certain tools, the developers now don't need to worry about the process of translating design into code. These tools fully optimize the time that your team spends on code reviews. They don't have to download and translate everything on their own. They can easily focus on refining the final product, programming functionality, and connecting the right data sources.


This is an important step and skipping this is as big a risk as skipping the complete code review process. The designer needs to be involved with the app during the QA phase. The tools will help in simplifying things down, but the designer's approval plays an important role in the end product. This is where the designer’s and developer’s patience comes into light. 

You both need to trust each other and give each other time to understand each other’s work. You need to respect each other’s disciplines so that you can both give and receive criticism on each other’s work positively. You don’t really have to master these abilities, but you have to consider them to maintain a healthy environment and do beneficial reviews.


This stage is all about reviews and feedback. It brings two teams together for one last before the project closes. The developer is responsible for the execution of the app. Designers and developers should discuss what went wrong, what could have been done, the improvements, the losses, and several ways that will strengthen their work in future projects and give better results. Read more about incorporating healthy code review approaches here.

Wrapping up

The designer-developer gap needs to be fixed and we hope that these steps will help you gain a better perspective and help teams collaborate better.

Never forget to appreciate each other’s work. Make the code review process a positive one instead of a demotivating one. Make sure that this gap doesn’t become a roadblock for the amazing ideas in your head. 

Let’s remember one thing: Good ideas always survive reviews!

Oct 30 2020
Oct 30

Building websites is not uncommon today, but what might be uncommon is building websites that will set the benchmark for all others to follow. Just stuffing your site with features on top of features is not going to achieve that benchmark, what may achieve it is the understanding of the needs and requirements of your business and consequently your site. The more the merrier is a great ideology to live by in life, but sometimes a website needs you to hold back your horses. 

If I talk about Drupal websites specifically, there are two roads to choose from while building them. You can either choose the traditional Drupal, which will encompass your whole site and build it from the ground up or you can choose to capitalise Drupal in parts as you may see fit and take leverage of other front end technologies as well, which forms the Decoupled Drupal

This scenario is often considered as crossroads for many and choosing either of the two becomes an insurmountable task. With numerous questions running through the web builders’ minds like;

When is the monolithic Drupal architecture appropriate and when it isn’t?
When is the decoupled Drupal architecture needed?
What are the benefits of the decoupled Drupal architecture and are there any drawbacks?

To appease all of your worries, I am going to go into the nitty gritty details to make your decision of moving from the Monolithic architecture to the Decoupled architecture an easy one. All you have to do is sit back and read. Before that, you can check out the difference between monolithic and decoupled Drupal architectures here.

The Monolithic Suitability  

Before making the pivotal call of switching to the Decoupled architecture, you have to analyse whether your current architecture is really in need of a change or not. A move to the Decoupled Drupal is going to cost you, in terms of money, time and efforts of your entire team, and if you realise later on that the advantages of the Monolithic Drupal architecture were working just fine for you, now that would be a situation you would definitely not want to find yourself in.

The Drupal logo is on the bottom left and the situations that are suitable for monolithic Drupal architecture are written in the centre.

So, let us understand suitability and appropriateness of the traditional Drupal approach by asking ourselves all the right questions and take it from there. 

Are you comfortable with using Drupal as is?

The traditional Drupal comes equipped with a lot of modules that enhance the functionality of your front end with just a click of the mouse. From making images turn into presentations to installing Google maps on your website, everything can be done by turning on the module provided for the specific need. If you are comfortable with this sort of system and website is doing well, you should stick to the monolithic approach.

What if you only have the most basic editorial needs?

The editorial needs are different for different categories of websites. Some rely highly on user interactivity and some don’t. In the latter’s case, decoupling is not required.  A news or a blogging site needs to have simplified features like content preview, layout management and in-line editing. With decoupling, these become complex and would only hamper the performance. If you cannot afford the added complexity, Monolithic approach would be more suitable to you.

Is it worth it for you to lose functionality?

The Decoupled approach essentially makes you part with some of the best Drupal features. If losing them is not worth it for you, you must reconsider the move. Certain features like UI localisation, account management screens and cross-site scripting, which enhances security, are inherent in Drupal and cannot be paralleled by a client-side framework. 

What is your budget constraint?

Drupal, being an open source software, is free. So, the traditional Drupal approach does not make you stretch your budget at all. However, the same cannot be said for the decoupled architecture. Not only would the development cost be high, but the maintenance costs will also be considerable. After all, you would be paying for experienced developers for their front end knowledge. So, can your budget handle that? 

Can you manage multiple teams? 

The coupled Drupal does not need multiple teams to manage the front and back ends, one team can do it all and managing one team is better than multiple teams. It is because communication and coordination is a given in a single team. Data models would be decided by it, endpoints would be created by it and tested by it without the involvement of a whole other department. If things are working for you this way and you know managing multiple teams or hiring different companies for the different aspects would be too much for you, the coupled Drupal is best for you.

Are your needs aligned with the Monolithic architecture’s frontend capabilities? 

This is the final question to ask. If the answer is yes, you should not make the move to the decoupled architecture. And if you know that you need more than the traditional Drupal can give you, like more control over the presentation layer, you must take the steps to make the switch.

The Decoupled Necessity 

Now that you know when the coupled Drupal is suitable, it is time to focus on the Decoupled approach. Like we have discussed above, the Decoupled approach becomes a tad bit more complicated to handle, yet website developers have been taking it up and with good reason. The decoupled approach counters all the pitfalls that the traditional approach may bring on you. And that is why it is often regarded as a need, which cannot be neglected. 

The Drupal logo is on the bottom left and the need for Decoupled Drupal architecture is highlighted in the rest of the space.

So, let us find out exactly when is the Decoupled Drupal architecture needed.

Do you wish to cater multiple channels and microsites?

The primary reason for choosing Decoupled architecture is the fact that it allows you to pull multiple content from its content repository and use it across varying channels. Many businesses often have multiple websites called microsites that they have to build on the go. In such situations Drupal becomes a need, because even if the microsites are no longer needed, the content would always be stored on it. Even if a brand wants to transcend its line of communication with its users past its website, Drupal can make it happen solely as a backend operator.

Do you wish to fancy up your website to be more interactive?

Making a web project increasingly interactive has become the need of the hour today. A web project needs to have an app like interaction with animations and transitions. Having complex user flows is also welcome. All of this means you will have to fancy up the code building your website with advanced JavaScript frameworks. Angular, Vue and React can easily do that and make your UI both elegant and interactive with the Decoupled approach.

Do you wish to benefit from diversification? 

Diversification of team in developing web applications may seem like too much of a challenge, but it is a challenge worth taking. The world is filled with experienced developers, who know what they are doing on the frontend, specialising in each and every aspect of the same. And if you look at Drupal specialists, the number isn’t as impressive as the former. So, if you want to benefit from the collaboration of various teams and get the best possible results, the Decoupled approach becomes necessary. A team with thorough knowledge of both Drupal for the backend and JavaScript and static site generators for the front end will essentially make you experience a result like never before.

Do you wish to become more independent?

If you use Drupal both for the front and backend, your project would be entirely dependent on it. There are developers who are alright with being reliant on one technology and there are developers who aren’t. If you fall in the latter category, the decoupled approach lets you be independent on the presentational aspect of your project. You can use other technologies and become as dynamic as you want to be. Such self-reliance also makes redesigning more convenient than it otherwise would be.

Plus, having free reigns over the front end is definitely going to give you the liberty to try out all of the latest and trending technologies there.

Do you wish to build an application?

If you are planning to build an app of your own, the Decoupled approach can be of great help for you. It can easily manage your content, data and even the users, while you focus on the presentation layer worry free.

Do you wish to not use all of Drupal’s frontend assets?

Drupal has numerous in-built features. From node edit screens to node view pages and admin screens, the list is quite extensive. What often happens is that all of these features become a burden and working around Drupal’s numerous screens becomes problematic. If you use Drupal just as a content repository, you would not have to worry about this hassle. You will be able to create with only what you want on the front end and still be able to tap Drupal’s impressive backend capabilities with the Decoupled Drupal architecture. Read more about the different options of decouplin Drupal here

The Decoupled Bonuses 

If your needs match to the ones that are mentioned above, then it is time to switch to Decoupled Drupal and it would be a prudent investment to make. The benefits of the Decoupled Drupal architecture are not just for the developers, it is for everyone involved in the web projects, the marketers included. The entire business feels the advantageous energy, when decoupling has been taken up.  

Write once, publish everywhere

Websites are dependent on their content as much as they are dependent on their performance. With the decoupling of Drupal, you get an opportunity to make your content shine and that too in more than one place. The diverse online mediums, encompassing all IOT devices, can easily be taken advantage of by a few clicks. The impressive blog that you just wrote for your primary website need not be limited to it, it can be published simultaneously to your microsites and your social media accounts amongst other platforms. This is what is meant by “write once, publish everywhere.”

Publishing platforms is written in the centre with all the various platforms mentioned around it in circles.

Improves user experience

The people who are going to use your website are the ones who need to be kept in mind when building it, so user experience is a key aspect. With the decoupled Drupal, you can build the UX of your site specifically for the needs of the user and shine. Let us try to understand how it can happen in the decoupled Drupal and not in the conventional one. Take a website that mandates constant re-rendering of content as an illustration. Now you tell me, is Drupal more equipped to handle such a need or is JavaScript the better option? I am sure you would go with JS because that is its forte. And decoupling lets you choose JS as many times as you want, leading to a better experience for your audience.

Moreover, UX is directly related to the performance of websites, which also improves through decoupling, although some might contend it. See when you decouple, you get more control and flexibility over the front end. With the client-side framework at work here, the request time lessens and can any user be possibly unhappy with that?

Capitalises JavaScript Framework

When creating interactive websites is at play, it pains me to say it but Drupal may seem a little underwhelming. It is JavaScript that can make the feat of interactivity on websites seem like a walk in the park. With JavaScript’s ES6 version and all its new features like destructed assignment and arrow functions, developers can get things done smoothly and swiftly. The traditional architecture will not let you do that. Since businesses all over the world are becoming reliant on interactive websites, the fully decoupled Drupal is becoming more and more appealing.

Gets work done faster 

I believe I have said this more than a couple of times and I need to say it again; the separation of front end and back end lets the developers work at their own pace. By decoupling Drupal, you will be speeding up your development process because it provides a clear separation between duties and work is done faster. The front-end will simply work on the UI and the backend will keep working in parallel to create suitable data structures for the former. So, your developers will be working at the same time and getting things done with no interruptions in their work. 

Another way to understand this is, content creators will not need to focus on the presentational aspects and the front end developers do not need to worry about the semantics of the content fields or their relationships. The former will work on the content and the latter would oversee the styles and layout tweaks. At the same time, a backend developer would not concern himself with the way a data point would be presented on the frontend. All of this is bound to enhance an organisation’s speed of work and its efficiency. Simply put, the decoupled approach personifies smooth working.

Gives the opportunity to be creative

With a decoupled architecture, you can let your creativity run free. Having worked with Drupal in the traditional sense, I know there are a lot of constraints, even the integration of Twig may pose some challenges while creating unique designs. However, when you go the decoupled route, all of it changes. You can build dynamic components using your creativity without letting Drupal’s rigidness hold you back.

Boosts upgrades

The decoupled Drupal boosts a website’s prospects of getting upgraded. You might have guessed this one from all the advantages above and your guess is right. A website has to undergo enhancements after some time, there is no refuting this fact. Many a time, the upgrade is put on halt because it would affect the current workings. However, with the decoupled Drupal’s departmentalisation, the front end can do an entire overhaul and the backend would continue to work like nothing is happening and vice-versa. Launching a new brand design has never been this easy.

On top of this, the decoupled Drupal also gives you the chance to build an application on the front end against a dummy web service API, which has the sole purpose of being a testing field. Since such kind of flexibility is unfound in the traditional Drupal architecture, decoupling proves to be extremely advantageous when it comes to revisions and upgrades. Check out some of the decoupled Drupal succes stories here

The Decoupled Fallout

With all that we have discussed so far, you might have come to a conclusion that decoupling is the right choice for you. It may even be, but you cannot make the decision until you have the full picture in front of you. There are indeed certain challenges in the decoupled Drupal architecture that have to be overcome in order to gain its advantages. Let us find out what they are.

The Drupal logo is on the left and the challenges posed by Decoupled Drupal architecture are written on the right.

Loses Drupal’s out-of-the-box features

As you may know Drupal comes with numerous out-of-the-box features, even if you are never going to implement all of them in your web projects, knowing they are there is still a benefit. Now, when you decouple Drupal, you have to part with many of them. A fully decoupled Drupal architecture will have none of the monolithic architecture’s frontend capabilities and that to many is a big disadvantage.

You will end up losing all of the following:

  • Security features like form validation and text sanitisation only come with the monolithic architecture.
  • Contextualisation features like in-place editing, previewing the content’s live result while editing and contextual links would be lost in the move. 
  • Content layout and display modules like Display Suites and Panels stop working when the front end is decoupled. So, getting variable displays for your content and constructing layouts would become difficult.
  • Notifications for possible system failure would no longer be sent to you in a decoupled architecture.
  • Drupal’s accessibility features that focus on user’s disabilities would not be embedded in the front-end code and you would have to be extra diligent for the needs of all users of screen readers.

Bugs become hard to identify web of systems 

The decoupled Drupal essentially becomes a web of systems. Although this has its own advantages, the disadvantages cannot be ignored. The most prominent being debugging. When you have more than one software working to build one cohesive website and a problem arises, it becomes extremely difficult to identify and catch it. The break could be in the request or it could be in the API, you would have to scour through everything to find out.

Creates more chances of failing 

Decoupling mandates a new hosting stack for your organisation’s infrastructure because of the separation of concerns. Traditionally Drupal is hosted on LAMP stack, Linux, Apache, MySQL, PHP, while JavaScript is hosted on a MERN or MEAN stack, MongoDB, Express, React/Angular, Node.js. This becomes problematic as one failure will lead to many. Supposedly, if proper caching isn’t provided by a Drupal site’s web service, whatever data your website would receive would most likely be obsolete. Therefore, decoupling Drupal paves way for an additional point of failure.

Brings coding complexities 

While building a decoupled infrastructure, you have to be very careful in the coding. It needs to be overseen that the front end logic does not get encoded into the API. If it were to happen, circular dependencies would be created, which would ultimately negate the purpose of decoupling. 

Increases the expense 

While monolithic Drupal, being open source is free for all, the decoupled Drupal is not. The need for new infrastructure and solutions to replace the ones provided by the coupled architecture would increase your development expenses. 

Apart from this, getting the nod on investment from the stakeholders to build a great content API, which otherwise would have been free, is no easy task. Furthermore, the maintenance of the decoupled aspects can often mean taking up temporary coupled remedies. And this stands against the initial investment objective; it’s a paradox, if you ask me.

The Bottom Line 

Now that you know everything about the Decoupled Drupal architecture, its suitability and the ways it would benefit you, it is up to you to make the final call of moving in its direction. The fact that decoupling Drupal has been gaining grounds in recent times should be the sole reason for making the switch. The buzz around it may compel you to take its route. However, your needs must be the paramount aspect in your decision. If you believe decoupling is aligned with them and the merits of Decoupled Drupal are easily overweighing the demerits, only then should you make the call for the move: because only then will you see a positive outcome from the move. 

Oct 30 2020
Oct 30

If you have worked with a designer, you probably have heard them complain a lot about giving feedback to developers to correct font sizes, spacing, or layout aspects. This can lead to a weakening of trust between developers and designers. Developers are often misunderstood on being ignorant about the details given by the design team

For instance, after a designer has spent their time working on designs for a website, and put a solid effort in every little detail of the design and the designs have been approved by the client. After a few weeks of the developers working on the technical part, the designers are asked to review the website. They get excited and open the website to see a very different one. They start noticing spacing, wrong fonts and colors used, etc. The designers get frustrated looking at all the details and that’s where the gap begins.

What could have been the problem? Well, maybe the communication gap turned out to be the cause of the misunderstandings between the two. These misunderstandings give rise to many questions. How many times did the two have a conversation? Were there motion prototypes? How did the handover look? Was there a handover meeting?

In this article, I will take you through some important points that will give you a better understanding of how to bridge the gap between the developers and the designers. But before that let’s understand the problems that arise during handover between the two.

Designer-Developer Handover

The handover of the design details from the designer to the developer is likely to happen at some point. It is important to plan out some time for a meeting that will help in giving a clear understanding of both.

There is no doubt that there can be initial hiccups once the two teams start working together. And this is why handover meetings are important. The opinions of the two can be contrasting but are definitely worth the effort. Always remember to ask questions on every page, design, feature, visual, component, etc. Ask for clarification wherever necessary. 

Compromise and build

The developers need to talk to the designers about something that they find wrong in the designs or maybe if they are unable to implement it for a reason. They should make sure they use non-technical terms while explaining. Instead of saying things like, ‘this can’t be built’ ‘we cannot build this’, back your points with valid reasons. If needed, give suggestions and alternative solutions that can be used to improve the designs and make it easier for the developers to implement. To look at an example, read the complete guide on website redesign strategy here.

What hinders the path of cross-collaboration?

The main challenge that disrupts collaboration between the design and development team is the way with which each team approaches problems. As the design is user-oriented, designers mainly specialize in user experience while the dev team is solution-oriented, the developers mainly target the features that aren't a part of the solution.

In fact, the approach of every team is correct in the context within which they operate but to bridge this gap between the two teams, they need to make more and more communication.

Communication is important

Communication between the two is very important. As discussed above, the design-dev meeting can reduce a lot of misunderstandings, so will conversations. It is important for both of them to talk to each other, collaborate, give each other ideas during the early phases of the project. Both of them have different roles and obviously very different perspectives. Learn more about the significance of communication between developers and designers here.

The Missing Link - Frontend Engineering

When the designers are done with the designing part, the development team comes in. This is where the ignoring of the details in the design components starts and the focus only shifts to the ‘functionality’ part. And that’s when the websites created start looking completely off from the visual designs. The front end developers are a big help in this situation. They reduce the gap between the visual composition and the functional page. 

The front-end developers have a good experience in CSS, JS, and XHTML that help them in creating functional prototypes that are very close to the visual compositions. With the involvement of front-end developers, the development team can easily concentrate on the functionality part and the design team does not need to worry about the ignorance of their work.

Let’s look at what steps the front-end developers can take to bridge this gap between designers and developers: 

  • Review specifications: To deliver a product that meets the branding guidelines and does not disappoint later, the developers should review the specs and notes beforehand and suggest changes as soon as possible, because deviating from the approved design in the later stages can cost you a lot. For instance, atomic design methodology can be very handy.
  • Understand user interactions: The front end developers can involve themselves in research to make sure you empathize with the users. This process will help you gain a better understanding of why you need to collaborate with designers. 
  • Give feedbacks: The frontend developers can share their insights with the designers, based on their experiences in visual designing, prototyping, and wireframing. Your feedback and reviews on a regular basis matter a lot even if you do not have experience in these fields. And in case you suggest changes in design, it will help your project manager to effectively manage your client's expectations. 
  • Ask questions: Ask relatable and good questions to remove the miscommunication norm in the workspace. This helps you avoid design requests at the last minute. You can also ask the designers for a quick informal review if you are confused on what to ask. 
  • Check-In Frequently: It is important to check in with the designers to help the developers become even more familiar with the project than they already are. Checking in frequently brings the team together and makes it easy for both the teams to approach each other and communicate effectively.


If both the teams are able to create a collaborative environment and give each other’s suggestions importance and try to have a better understanding of each other’s work, it becomes easy for them to work together and respect each other. The front end developers are a great help, always. Their suggestions and interest in design and development are heard more during the meetings!

Oct 19 2020
Oct 19

“Development workflow aligns team members, keeps them engaged, and drives a balance between speed and quality of code changes.”

In today’s competitive environment, organizations are constantly engaged to create new ideas that can act as the leading front doors to building businesses. Starting a new web development project means a blank slate that comes along with the opportunity to try out new technologies. Over the past few years, the concept of developing a strong and influential workflow is no longer limited for the sake of process only. In other words, having a robust development workflow is looked at as an opportunity that can make a huge difference to the efficiency of your team as well as the quality of your product. 

However, when it comes to Drupal development workflow, things are not easy as it may look. That is to say, many Drupal-based organizations suffer from a standard process that needs to be adopted and implemented. Consequently, it leads to real problems, right from a chaotic approach to code submission to a review of the inability to determine where and why things inevitably break.

Therefore, this article is written to demystify the basics of Drupal development workflow to appeal to a wide audience including both work from home as well as work from office. Moreover, after reading this article, you will become familiar with the development techniques we employ to achieve the best possible results and with how we adapt to alterations during development.

Forming a standard development workflow vis-à-vis specific project’s requirements

While perfect planning may seem like the key to a worthy goal, there are chances that even the most perfect plan may require a change in the development workflow. Yes, you heard it right, change in development workflow strategy is not breaking news but a part of the job which every organization undergoes. Managing development workflow helps the organizations to stay flexible and responsive to change without slowing down the work at hand. 

Since different projects have a different workflow, it becomes important for businesses to implement, plan, and fine-tune the architecture and development practices in accordance with the project-specific need. Let's take a look at a few scenarios:


Monolithic architecture is a traditional way of building applications. However, this workflow is harder to implement changes wherein the application is large and complex because of highly tight coupling. Any slight change in code affects the entire system which often makes the overall development process much longer. Well, in a situation like this, something like microservices architecture is required which has a different workflow than monolithic architecture. Organizations that require a collection of smaller independent units rather than a single unified unit must shift their development workflow to a microservices architecture wherein the entire application is divided into independent services, owned by small separate teams.  

Pattern Lab

Organizations that are design-focused may require a front-end framework or a completely different workflow that can offer a convenient and easy way to enforce component-driven design. Or let us envisage that you have a project where designing is the foremost thing for which you may essentially look for a refreshing way to create sophisticated designs. In both situations, the standard or existing workflow might not hold up and the development team has to look for a workflow that can serve as a hub for your design system. Born out of design principles, Pattern Lab can be used in the aforementioned situations to create and maintain thoughtful UI designs. Development teams that are well-equipped with Pattern Lab create reusable components, thereby speeding up your team’s workflow, and further allowing you to save huge amounts of time and money in the process.

Decoupled Approach

In traditional Drupal websites, Drupal handles the front-end and the back-end functions single-handedly. As a matter of fact, in addition to being a robust content store, Drupal’s powerful frontend takes care of your site design, behavior, usability, and management. It’s perfect for creating impressive visual designs and cutting-edge interactivity. However, with consumer touchpoints like connected devices and wearables taking center-stages, organizations are looking for front-end technologies like React or Gatsby which can help them deliver the best digital experiences to potential clients. And in order to fulfill this need, organizations need to make necessary changes in their development workflow. This is because the Drupal development workflow that was applied for creating websites with traditional approaches may not be suitable for decoupled Drupal architecture. With separate teams working on the frontend and backend side of things, your standard development workflow would have to be tweaked in a way that both the teams are able to work parallelly. Learn more about monolithic and decoupled Drupal architectures here.

Having the right project management tools

Project management refers to an umbrella term which is a compendium of the application of knowledge, skills, tools, and techniques that are required to meet the project requirements. The main intent of project management is to produce an end product that will affect some change for the benefit of the organization that had instigated the project. It is basically the initiation, planning, and control of a range of tasks that are required to deliver the end product using various tools. 

Project management tools are vast and can serve many different functions. For your consideration, we have listed down some of the most common project management tools which play a pivotal role in the Drupal development workflow. So, let’s give each one of them a quick look.


Screenshot of confluence tool

Confluence being one of the most popular collaboration tools helps you create, collaborate, and organize all your work in one place. Irrespective of the team size and type including people with mission-critical projects to people looking for a space to build team culture, Confluence serves as a team workspace where knowledge and collaboration meet in a more open and authentic way. Organizations that utilize Confluence are able to make quick decisions, gain alignment, and accomplish more together. Some of the key features of Confluence include: 

Page: This is the place where your content lives. This feature allows you to create pages for almost anything, starting from project plans to meeting notes, troubleshooting guides, policies, and much more. 

Space: Pages that you create are stored in spaces. They are nothing but workspaces where you can easily collaborate on work and keep all your content organized. You can create as many or as few spaces as per the requirement. However, it is always suitable to group related content together in the same space.

Page Tree: This feature organizes space content with a hierarchical page tree in order to find work quickly and easily. It also nests pages under related spaces and pages to organize pages in just about any way. 


Screenshot of bitbucket tool

Bitbucket can be called a real worthy competitor to GitHub which comes with different operating systems to provide support to the professional teams. Being a section of the Atlassian family along with tools like Confluence, Jira, etc, Bitbucket is made in such a manner that it provides complete support to the technical teams to explore the entire potential. Bitbucket offers organizations a central place to manage git repositories, collaborate on the source code, and guide through the development flow. A great way to extract maximum advantage of everything that Bitbucket offers is to integrate it with your task management software. The deployment of Bitbucket is made in three different options which include Bitbucket cloud, Bitbucket data center, and Bitbucket Server. Besides these aforementioned advantages that Bitbucket offers, it also allows user to use some awesome features that include:

  • Access control: This feature allows you to restrict access to your source code.
  • Workflow control: Using this feature, you can enforce a project or team workflow.
  • Pull requests: Can be used with in-line commenting for collaboration on code review.
  • Jira integration: This feature gives access to full development traceability.
  • Full Rest API: Provides easy access to building features custom to your workflow if they are not already available from our Marketplace.


Screenshot of Jira tool

Originally built to track and manage bugs in software development, Jira has now become a famous agile project management tool that helps teams to manage their work under a single roof. Products and applications built on the Jira platform help the team to perform various functions such as plan, assign, track, report, and manage work. If you wish to bring your team together for everything, right from agile software development and customer support to managing shopping lists and family chores, then Jira is your tool. Jira is a family of products providing several products and deployment options that are purpose-built for Software, IT, Business, Ops teams, and more.

Three products have been built on the Jira platform: Jira Software, Jira Service Desk, and Jira Core. Each of these products come with built-in templates for different use cases and integrates seamlessly, so teams across organizations can work better together.

Jira Software: Used to plan, track, and release world-class software.

Jira Service Desk: Used to give customers an easy way to ask for help and your agents a faster way to deliver it.

Jira Core: Used to manage the business projects including marketing campaigns, HR onboarding, approvals, and legal document reviews.

Implementing CI/CD Pipeline

A CI/CD Pipeline implementation, or Continuous Integration/Continuous Deployment, is referred to as the backbone of the modern DevOps environment. The CI/CD pipeline is held responsible to bridge the gap that exists between development and operations teams by automating the building, testing, and deployment of applications. 

In DevOps, a continuous and automated delivery cycle acts as a catalyst that makes fast and reliable delivery possible. As a result, there is a need for proper continuous integration and continuous delivery (CI/CD) tools. The marketplace is flooded with a wide variety of CI/CD tools that can be used to speed up delivery and ensure product quality. Some of the tools are given below:


With a front end built in Drupal (Devmaster) and a back-end built with Drush, Symfony, and Ansible, DevShop is a "cloud hosting" system intended for Drupal users which makes it easy to host, develop, test as well as update drupal sites. 

DevShop uses git to deploy the sites, thereby allowing you to create unlimited environments for each site. Moreover, it’s very easy to deploy any branch or tag to each environment using DevShop. Data including databases and files can be deployed between environments. Further, you can run the built-in hooks whenever code or data is deployed, or simply write your own.


Built with Java, Jenkins is an open-source automation server wherein the central build and continuous integration process takes place, regardless of the platform you are working with. With Jenkins, organizations can easily escalate the software development process by simply automating it. This particular powerful open-source server holds the potential to manage and control software delivery processes throughout the entire lifecycle, including build, document, test, package, stage, deployment, static code analysis, and much more. 

Checks during Pre-Code merge

There are certain CI/CD tools that are used by organizations as a strategy to help development teams integrate code easier and find bugs before they are released into actual production. 

-   Code Review 

Code review refers to a systematic examination to find and remove the vulnerabilities in the code that are often not readily apparent when compiled, such as memory leaks and buffer overflows. 

Example- Sonarqube, an automatic code review tool that is pretty helpful to detect bugs, vulnerabilities, and code smell in your code. 

- Drupal 9 Deprecation

Instead of working on Drupal 9 on its own git branch from the scratch, Drupal 9 was built in Drupal 8. Further, it involves the removal of all deprecated APIs and changing the remaining small number of deprecations to be deprecated for Drupal 10 instead. 

Example: Drupal Check, this tool allows you to run a standalone PHP executable from the command line and get a report of deprecated code, if used any. Access the definitive guide to Drupal 9 to know more.

- Security Checks 

It refers to the process which involves a Drupal-based site and gets a high-level overview of the site’s security posture to avoid future vulnerabilities or threats.

Example: Snyk, a security tool that developers use and love. It helps software-driven businesses to develop fast and stay secure. 

- Prod code performance reviews

It refers to the process wherein errors are detected that might have been produced during the development process and can potentially hinder workflow productivity. 

Example: Sentry, a leading SQL Server performance monitoring tool that helps developers to diagnose, fix, and optimize the performance of their code.  

Checks during Post-code merge

Just like pre-code merge, there are certain tools that act as a strategy to help development teams to examine and get an insight into the overall scenario after pre-code merge.

-  Performance 

It refers to the process of determining the speed, response time, stability, reliability, scalability, and resource usage under a workload.

Example: Sitespeed.io, a set of open-source tools that allows you to monitor and measure the performance of your website with ease. Read Drupal performance optimization guide to know more

-  Accessibility 

It refers to the process to ensure that the site built is usable by people with disabilities like hearing, color blindness, old age, and other disadvantaged groups. 

Example: Pa11y, a command-line interface with a job function to load web pages and highlights accessibility issues, if any. This tool is quite useful to run a one-off test against a web page. Read more about Drupal’s accessibility features here

- Warnings/Errors

The process to identify and configure the logging of a few warnings or errors that can further be used to debug your application or website.

Example: Jenkins Next Generation Warnings, a plugin used to collect compiler warnings or issues that are reported by static analysis tools and visualizes the results. 

- Periodic load tests on API level

It refers to a way that allows you to check whether your application is robust enough to handle the load you want it to handle before your users find that out for you. 

Example: k6, an open-source load testing tool to catch performance regression and problems at an earlier stage thereby allowing you to build resilient systems and robust applications.


To conclude, we hope this article has given you a good idea of what a workflow is and how you can use it in order to run your business. To be upfront, planning a development workflow for Drupal 8 projects takes a little bit of effort as well as time but it pays off considerable dividends in the near future. In other words, organizations with a good workflow have seemed to receive a part of the profit in terms of increased productivity, reduced stress, and a better quality of working life in general. All you need to do is give yourself some space to get started and make gradual improvements over time. Doing so will help you reap the possible benefits sooner rather than later. 

Want to know how to automate your own development workflow? Feel free to contact us at [email protected] and our industry experts will help you optimize your development workflow. 

Oct 16 2020
Oct 16

The concept of atomic design was introduced by Brad Frost and it helped accelerate the process of creating modular designs. The universe is made up of a set of elements, that are the building blocks of everything around us, and these are known to us as the periodic table of elements. All these elements have fixed properties that define each of them. The same way in which these elements combine together to form the universe, the design system is created by the combination of different elements of atomic design.

Let’s dive into these elements and understand the process!

The elements of Atomic design written on a blue background


We have all read about the atoms in chemistry. They are the building blocks of matter. Every chemical element has different properties and they cannot be broken down without losing their meaning. Now, if we relate the same thing to our design system, the atoms are the foundation building blocks of the user interface. These atoms have basic HTML elements, for example, buttons, labels, spacings, etc that cannot be further broken down without suspending its functions.

Different elements of a search option


In chemistry, molecules are a group of atoms attached together that can have different properties. Two molecules made of the same atoms behave differently and show distinct properties. In the same way, Molecules in the user interface are a group of elements working together. For example, if we put the label, button, and search input together, we will get the search form molecule. After they are combined together, they have a purpose and define the atoms that are put together. To construct a user interface, we assemble elements to form molecules like the search molecule.

Search bar


Organisms are comparatively complex UI components. They form a distinct section of an interface. The organisms in the design system are a group of molecules. The search molecule that is created by a group of atoms can be combined with another molecule that creates complete page navigation to make an organism. 

The organisms can have similar or different molecule types. They can be a search form or a logo image, etc.

Search bar with logo framework


The chemistry analogy ends here. You just read about the basic structure of a design system i.e. the atoms, molecules, and organisms. Now let's see how they can be used to create a consistent product.

At this point we see the design coming together to form pages. Templates articulate the design's content structure and place components into a layout. While crafting a design system, it is important to see how the components look and function when put together. You basically create a skeleton of a page. An important characteristic of templates is that they focus on the page’s content structure in spite of the final product.

Wireframe of a webpage


Pages show how the UI looks like when placed with everything in place.
This stage is the most important and concrete stage of all. We are able to understand and have a look at how the page looks when real content is applied and if everything is looking and functioning as planned.

Home page of a website

Why go for atomic design?

Atomic design involves breaking off a website into the elements that we just talked about and then forming a website. Now that we have understood them, let’s understand why atomic design should be used and how it makes our life easier.

Mixing and matching components

When components are broken down, it becomes easy for you to understand what part of the website can be reused and mixed to form molecules and organisms.

Creating a style guide

If you have created your site according to the atomic design guidelines, then the atoms and molecules created before the site is built can be a help as a basic style guide.

Consistent code

The chance of writing duplicate code is reduced with atomic design. It also becomes easy to understand which components are used for different parts of the website.

Understandable layout

The documentation of atoms, molecules, and organisms and where they are being used makes it easy to understand what each part of the code is representing. The best part is that it is much easier to explain the codebase to a new developer.

Quick prototyping

Making a list of elements before the website creation starts helps you mockup pages instantly by combining the elements of the page.

Fewer components

If the website creator has a list of all the atoms and molecules, he will more likely use the existing elements rather than creating new ones.

Easy update and removal

With one atom, molecule, or organism changing at a time, it is easier for any update to be done across all other instances of the site. In the same way, the removal of unwanted components becomes easy.

Implementation of atomic design

Getting started with atomic design needs you to understand every part of it and dividing into the basic elements that are, atoms, molecules, and organisms. You can always start by conducting an audit. This will help you look into discrepancies and areas that are lacking. This will make sure that you and your team are familiar with the structure of the website. 

After you have conducted the audit, look for a platform where you can build your design system. Take help from the developers to know more about which tools will be more efficient. Make sure that the tool that you have chosen is easily accessible by everyone in the team. Tools that will help: 

Now that you have a good understanding of the design system and its principles, you can start building your website. Start by the construction of components piece by piece and don’t forget to document what page every component is for. Read about web components and component-based development to know more.


The atomic design provides a clear methodology for creating a design system. It makes sure that we are explicit with our creations and also that our designs are more manageable, consistent, and that the user interface is faster than ever before. For a faster and more efficient user interface for your website, contact us at [email protected]  

Oct 15 2020
Oct 15

Websites have become a necessity in the 21st century. From gathering traffic on them to creating a buzz about its brand and resultantly leading to a higher sales figure, websites can do it all. However, not all websites are able to do that. A successful website is often considered to be one with the best user experience and performance. A low bar at these may just be the doom of the site developers. And when you combine the impressiveness of the site’s UX and performance with its overall aesthetic and product quality, success is almost guaranteed.

So, the process of building a website has to be done with the utmost care and expertise because doing a half-hearted job at first and regretting it later would not be prudent for anyone. The build and functionality of the website entirely depends on its developers and the CMS at work. Choosing the right architectural approach should be the first priority for all business owners and site builders. 

Getting into the architectural aspect makes me highlight the two variants that are the most popular amongst Drupal websites, the monolithic or the traditional architecture and the decoupled architecture. This article will accentuate all the areas of these two and discuss their aptness for different business needs.. 

Introducing the Contenders: Monolithic and Decoupled Drupal Architectures

Drupal is a pretty versatile content management system, it has the capability of building your websites for you, taking care of each and every aspect of the same. That should sum up Drupal’s capabilities, yet it doesn’t. With its different forms of architectural options available, Drupal has become the embodiment of versatility. The choice of deciding between Monolithic and Decoupled forms of Drupal architecture is proof of just that.

Starting with Monolithic architecture, in the terms of a software engineer, it means a single software that has the potential of handling every aspect of work done on it or with it. A monolithic architecture will always be single-tiered, wherein the UI and the code for data access are merged into one platform. And that is what Monolithic Drupal architecture or the traditional Drupal architecture means. The coupled Drupal is well-equipped to make a website up and running, both in terms of the front-end and the back-end. You would not need to rely on anything else, if taking the Monolithic approach. You would have all the Drupal resources in your corner, as your project would be entirely nestled inside it.

Drupal is regarded highly in the community for its back-end capabilities, its front end deserves equal regard. Using Drupal’s many behaviours, themes and templates, you can easily create impressive visual designs that would also provide state-of-the-art interactivity to your presentation layer that can be customised on the go. And there is more, any problem with your site’s design, behaviour, usability and management can easily be tackled by Drupal’s frontend aspects. So, it won't be wrong to presume that the traditional Drupal is a versatile software easing the process of building web applications. 

However, if you want to tap into the other frontend technologies, then there is a possibility for that as well, with the use of Decoupled Drupal architecture.

In simple terms, decoupled Drupal architecture separates the front end from the back end. The Decoupled Drupal separates the UI from the presentation aspect. Although the UI and the content management would be provided by Drupal, you would have free reigns over the presentation layer. You would not be bound to use any of the themes and templates. This approach mainly needs Drupal to act like its content repository. Although it is a relatively new trend in the CMS, many all over the Drupal community have taken it up. It has been gaining more and more traction because of the freedom Decoupled architecture provides to its users offering the advantage of capitalising on the many front-end technologies available outside of Drupal. Learn everything about Decoupled Drupal here.

Two rectangular representations are shown to highlight the difference between traditional Drupal architecture and decoupled Drupal architecture.

In essence, both Monolithic and Decoupled approaches can be deemed similar in the sense that they have the back-end Drupal technologies. However, when the front-end or the presentation part comes to play, they start to seem vastly different. 

Different Ways of Leveraging Decoupled Drupal Architecture

Now that we know how the traditional and Decoupled Drupal architecture are different on the foundational level, let us delve deeper into the different ways of decoupling Drupal architecture.

Drupal was founded as a monolithic software performing every aspect needed for website development. This architecture has total control over a project, in terms of its presentation, all the visual elements along with in-place editing and layout management as well as in terms of data. In an attempt to not sound like a broken record, I would add that Drupal in its traditional sense is still the most used version of the software primarily because of the control it gives to the editors.

Coming to the Decoupled architecture, the story changes. Like I have already told you, the Decoupled approach mainly relies on Drupal for its backend capabilities, the front-end may or may not entirely become independent of Drupal.There are two broad categories of this architectural approach.

The Drupal logo is in the center with four dialogue boxes that are describing the four approaches of Drupal architecture.

Progressively Decoupled Drupal Architecture

A major motivation behind taking up the Decoupled approach is the developer’s wish to use more JavaScript. However, the use of JavaScript does not necessarily mean that you have to give up Drupal’s front-end action. With the progressive approach you can do both. You get to keep Drupal’s front-end and add the JavaScript framework of your choice to it. JavaScript framework can be used for a block, a component or an entire page’s body. 

The layout of a progressively decoupled Drupal architecture is shown to depict its many heads.

However, there is one thing to consider in this approach, more use of JavaScript on a page will make Drupal’s administrative abilities less in control. Read more about progressively decoupled Drupal here.

Fully Decoupled Drupal Architecture

In a fully decoupled Drupal application, you see a full separation of the presentation layer and other elements of Drupal.What this means is that the client’s framework becomes a server side pre-renderer, which ultimately leads to uninterrupted workflow. The CMS is a data provider in this instance. And an API layer acts as the connection between the two, retrieving data from the back end and providing it to the front end. It has to be understood that many Drupal features like in-place editing will lose their functionality or rather become unavailable in this approach. However, you will be able to exert a great deal of control over the presentation layer with other available technologies, React, Angular and Gatsby being a few of them.

You can also go for fully decoupled static sites. To tackle the increased complexities of JavaScript without affecting the performance of a site, static sites were introduced. For this approach to work, a static site generator like Gatsby is a great tool to use, which will take data out of Drupal and generate a site for you. So, Drupal basically becomes a data source throughout the process. 

Being API-first CMS: Drupal Web Services

Like the name suggests, being API-first means building an API before building a web application, which is basically created around the former. For the Decoupled applications to work effectively, Drupal has to be equipped with a top-knotch API that would essentially be the thread holding the front and backend together. The Drupal community has done a great job in this matter. 

The provision of pretty impressive web services that have been years in the making are proof of that. REST API can be considered as the paradigm here, however, for the applications that do not communicate using it, Drupal has other web services modules as well. Since Drupal was able to provide these and transcend the degree of functionality provided by REST API, it is all set to become the best open-source API-first CMS.

Primarily, the Decoupled Drupal has been known to use any one of the three APIs I have mentioned below. I would like to add that since the Monolithic approach does not need an API to provide a connection, these would not be relevant while using it.


REST or Representational State Transfer API is one of the most popular ways to let the HTTP client get the responses it wants from the content repository, which is Drupal. Drupal  provides this web service out-of-the-box that includes RESTful Web Services, Serialisation, HAL, and HTTP Basic Authentication. With its proficiency at executing HTTP requests and responses, it easily aids in operating the data managed by Drupal, be it comments or nodes or maybe even users. 

A diagram represents the way an HTTP request and response works through an REST API in the Decoupled Drupal application.

In a simpler sense, REST API is like a mediator along with the HTTP client because they help the front and backend to work harmoniously on any framework they like. 


JSON:API is gaining momentum as the go to mediator in the Decoupling process of Drupal. A reason for the same is the fact that it is the better version of REST API. It offers a relatively high degree of productivity in comparison to REST API with minimum requests to the server and providing related resources without asking. It is phenomenal at filtering, pagination and its sorting capabilities along with caching use are almost impeccable. You tell me how can it not be the go to option here?


GraphQL is a query language that was developed by Facebook. It is used for custom queries to retrieve data from the backend with a single request. The GraphQL Drupal module works on the same principle and even lets you update and/or delete content or an entire configuration. Moreover, GraphQL has the ability to act as a base-line for the generation of custom coded schema or its extension. I find this one detail to be really helpful when the plugins are to be used to form a sub-module. 

Check out more alternatives on the modules available in the decoupled Drupal ecosystem here

Front-end Technologies

Apart from the different APIs used in the Decoupled Drupal architecture, the languages used are also quite distinct from the Monolithic version of the software. It is because the traditional Drupal does not have them as its core. Although it has its own JavaScript Library, the JS Framework is out of its jurisdiction. And this is one of the major reasons for seeking the Decoupled approach.
Let us have a look at some of these.


A lion’s share of frontends are designed with a JavaScript framework at its core. Since JS offers a higher degree of interactivity, it often acts as a wiser choice. There are three popular frameworks at use which are;


React is known to deliver the most amazing digital experiences when it is combined with Drupal. With big names like Facebook, Reddit and Airbnb as its users, it does not come as a surprise. React has the ability to split a code in varying components, which is immensely helpful in debugging and enhancing the reusability of the code. If you want to produce results that are both SEO friendly and very responsive, then React is the perfect option for you.  


Angular was initially introduced by Google in 2009, but the 2016 re-released version was entirely rewritten to make the development of mobile and web applications very easy. This is especially true because it uses HTML in the simplest form to clearly define user interfaces, eventually making web applications a trifecta, interactive, functional and extremely hard to break. Perhaps, this is why The Guardian and Gmail are proud users of Angular for their frontend aspects.


Vue is a JavaScript framework which is primarily used for building UIs and single-page applications. Its best implementation is seen in creating the view layer of a web application. Since Vue is quite lightweight, it makes it highly adaptable. It can also integrate itself with other libraries and tools to get whatever is desired in an application. The combination of Drupal and Vue is indeed a powerful one, as the former control over the backend and the latter’s client side handling make the creation of large-scale applications a walk in the park. 

Static Site Generator 

A Static Site Generator or an SSG is a tool that is used to build static websites which have a pre-existing set of input files. It is often regarded as a middle ground, wherein a hand-coded static site is used with an CMS. There is one particular SSG that deserves to be mentioned.


An open source framework that is based on React, with every advantage of the JAMstack (JavaScript, API and Markup), be it performance, scalability or security. This is the simple definition of Gatsby, impressive, isn’t it? It would be suffice to say that Gatsby is jam-packed with features, the best of which is of course, its ability to pre-generate pages, making it much faster than the dynamic sites. You will actually be able to build a complete website faster than many will be able to create just a prototype.


Metalsmith is one of the simplest SSGs to be used and it is pluggable. It can effectively produce static build files by extracting information from the source files, manipulating it and writing it to files in a destination directory. These indeed seem to be a lot of files. From grouping files to translating templates, it can perform numerous manipulations, all using its plugins and all consecutively. Not only does the use of plugins simplify things, but it also provides the user the liberty of choosing and implementing only the ones that he needs.


Tome  stores your information in static JSON files, which are generated from static HTML form your very own Drupal site. With Tome, you can choose from the large number of themes and modules found in Drupal, create content and simply push the static HTML to production and your work is done. The fact that it allows you to use Drupal without any security or performance worries is another bonus.

All of these are regarded as the top-notch front end technologies for web building and you may very well know that nothing can beat Drupal at its back end game, so with Decoupled Drupal you get to have the best of both worlds, the worlds inside and outside of Drupal.


The fundamental difference between Monolithic and Decoupled architecture can be detected with the degree of usage of Drupal’s entire software. There is no right and wrong approach amongst these two, when choosing Drupal for your project. Your choice will come down to the needs of your project and what your intentions are for the same. For instance, you might not want to create JavaScript interactions for your project, so you could use Drupal as is, which is the Monolithic version. 

On the contrary, if your project mandates the use of JS or static site generators, the traditional approach will not cut it for you. Decoupled Drupal has to be taken up and there is no harm in that as well. There are so many big names, like the Weather.com, NBC and Warner Music, who have been using the Decoupled architecture and they have experienced great results. 

Whatever approach you may think you want has to be aligned with the needs of your project. And when they do, trust me, whichever approach you will choose, it would be a winner for you.

Oct 13 2020
Oct 13

The virtual sector has become increasingly prominent today. From trading shares to buying groceries, every single aspect of our life can be fulfilled in the virtual world. And do you know what lies at the heart of this world? Since it is online, you must be thinking that a website has to be at the core. And you are right to think so. A website is the foundation of every online business, from blogs to e-commerce, every virtual service provider needs a website.

Now, just building a fully functional website is not enough. You have to keep updating it every now and then, simply because what was trending two years ago is considered antiquated today, and we do not want your website to be regarded as out of fashion. 

When making the decision of revamping your website, you have to consider something very carefully. And that is the difference between website refresh and website redesign. If you want minor changes to be done in your website, like changes relating to its appearance, you would call it freshening the website. On the other hand, if you want to change your website completely, you would need to redesign it. This would transform the makeup of your website, from the content to the appearance and sometimes even the code. It is like converting a hatchback into a limousine, even though it would be the same car, it would be tremendously different.

So, if you are planning to redesign your website, you have landed in the right place. This article would accentuate everything related to redesigning a website; let us begin with the reasons for the same.

The Need for Website Redesign

There is a pink and green background with a clock depicting the need for website redesign has come along with the reasons.

Website redesigning is a giant undertaking that can be both costly and time consuming, so you can’t just do it on a whim, there have to be reasons for the same. Understanding those reasons is as important as the actual undertaking. 

I have compiled a list of common issues faced by website developers and operators that have compelled them to overhaul their websites, so that you can get an answer for the important question, that is, when should websites be redesigned. If you are experiencing more than a couple of them, consider it as a sign to say goodbye to your current website. 

Expansion of the company

Every business is in the market for growth. This growth means that they would enhance the products and services that they provide at one point or even start a whole new department. A website is like the gateway for the customer to know your services, and if it isn’t doing that, you will potentially lose your customers to your competitors. So, remember that, growth is always followed by your website’s redesign.
Changing market trends

If there is one thing that is fickle in this world, that would be the market trends. These change faster than light making your head spin with it. One day the gaudy and eccentric website are all the rage, and the next, minimalists reign online. The point is that your website has to align with the market trends, especially in terms of design. 

Unresponsive to some users 

By responsive, it is meant that your website can easily be accessed through any device, be it a smartphone, a tablet or a desktop. Sadly, there are a number of websites that are inaccessible through a smartphone and that just about destroys your leads. Adaptability or responsiveness can be achieved through redesigning.

Poor conversion rates 

The primary purpose of a website is to generate sales, if it is not doing that, then what is the point? Your customer base is basically decided by your website and how compelling it is for them. The more interest it generates in the customers, the higher the chance is that they would make a purchase. Having too complicated text packed with corporate jargon, not having enough CTAs, lacking in the aesthetic aspect; all of these will contribute to less conversions from your visitors. And the only way to overcome this is redesigning.

Complicated user interface 

A good website is the one that allows the user to easily maneuver around it and get the full experience of what the developers wanted to provide. If that is the case, then your website lacks in the functionality part and everything on it is as good as useless. The solution here is to simplify the user experience and redesigning is the route to go.

Revitalise your brand

Brand image is very crucial because it is how customers would perceive you and your brand. It is up to your brand image to make the customers think happy thoughts or get all woeful. Coca-cola is always associated with happiness and joy, because that is the image they have built. A website helps a great deal in that. Now, if you think that your brand’s perception is not aligning with its core, you would need to redesign it to make the alignment happen.

Now, that you know why websites need to be redesigned, let us get into the process of doing it.

The Website Redesign Strategy 

There is a bulb on a dark background personifying an idea for website redesign and on the left the strategy for the same is written in points.

Redesigning a website is not something that will happen in a day. It needs time and resources to be put to good use. The process would be extensive, you would need to be aware about a lot of things, ensure everything works for you and aligns with your vision for the future of the website. Even the slightest of mistakes can become tragic for your website. That is why, a holistic approach has to be taken into consideration and I am here with the website redesign tips you would need for that.

Analyse the expense and its bearing on you 

The first step towards website redesigning commences when the budget for the same has been decided. The financial implications of website redesigning have to be considered, you cannot go wayward with the money; that would not be a wise choice.

Your website will be your first impression on a consumer and you would want it to be impressive. For that to happen, you would need financial resources that are substantial. Don’t take up redesigning until you have the resources, because doing a half-hearted job is just going to be a waste and you won’t be winning any website awards for that. So, analyse the expenditure, set aside the needed amount and delve right into it.  

Inspect the existing website

Once the money is ready, the process officially commences. And it does so with the past and its inspection. By past, I meant your current website, which would become your past after the redesigning. Your website, as it may be, would have done something for you, that is why you had it for as long as you have had it. 

Micro analyse every CTA, every image, every click that you received and how often that was. From bounce rates to time spent on a page, from the number of visitors to the number of sales, inspect everything and that too thoroughly, do not leave anything uninspected. I am emphasising on everything again, because it is crucial. This is the beginning and a successful beginning results in a successful end result.

If you want help in doing all of that, Google Analytics can sort you out. Once you have done all of this, you need to take note of the things that work and the things that don’t. The advantages would move further with the redesigning, while the disadvantages will be worked on until they are no longer a disadvantage. 

You must be wondering why all of this is necessary. Why not just start afresh? The problem with starting from scratch is that you might end up doing the same things again, which would only result in wasted time, effort and money. The inspection of the current website would not only give you a direction and a blueprint of the redesign, but it would also save the extra effort. So, why not?

Establish priorities to make goals

After the inspection is done, you would have a fair idea as to where you stand with your website. Knowing the key areas that are hampering your conversion rates or even your visibility on the web, helps you understand and establish priorities for the redesigning.

For instance, your content could be amazingly good, engaging and informative, however, the way it is presented makes it seem boring at best. Therefore, changing the content should not be a priority, rather its presentation should be. 

So, prioritising the areas that need to be focused on from the get go is an important step in website redesigning. A reason for its importance is that prioritising helps in making the design goals. 

Once you know what you need to focus more on, you could start working on that first and get better results. It is like knowing your weaknesses and working on improving them. I was weak in science in school, pathetic really, so I put in an extra effort by prioritising and started seeing the results. In website redesigning, there won’t be any mysterious scientific concepts, but you could endeavour to elevate your visitor count, enhance domain authority or improve your SEO rankings and eventually increase your sales. All of this is achieved by prioritising your goal. You can’t simply take on everything at once, you need preparation and this is it.

Create a unique brand image 

If you have a website, you are a brand. The question is whether your brand is appealing enough to customers to pull money out of their pockets and buy from you? The answer lies in the image you create for your brand. A good way to create an impactful persona for your brand is your website and redesigning the same can easily do that. 

The first thing that a customer would see on your website should effectively depict what you are about. The user should not have to decode it, trust me, he would go to your competitors website instead. And do I have to say that we do not want that?

A website's homepage is showing a lot of attractive offers, which is should be an aim in website redesign strategy.Source: Amazon

This is Amazon’s home page, and it should be considered the benchmark in branding. I would not leave this website until I have scanned through the “Top picks for your home.” With so few words Amazon has portrayed all that it is about and engaged the user. 

I know every website cannot be like this, but the conciseness can be achieved, it has to be. That is the core of branding. Your redesign strategy has to ensure that your brand image works in your favour rather than against it, make it unique, make it enticing and make it worthwhile for the customer.

Assess the competitors 

You may be at war with your competitors, but that does not mean that you cannot learn from them. Assessing the ways your competitor’s websites look, the kind of services they provide, how functional they are can help you a great deal. You must be wondering why. It is because you and your competitors are in the same market, catering for the same customers, whose needs and wants are the same; apart from this their likes and dislikes would also be the same. So , if they like something that your competitors are providing, you can make a change. What could be the harm here?

Cater to your audience more than yourself 

A website’s success entirely depends on its users, they are the ones who can make or break it. So, making a website keeping in mind the end-user’s thought process and needs can make a difference between the success and failure of a website. 

Obviously, your website is not going to be for everyone, it has to have a target audience or a buyer persona. Is it meant for the retired or the middle-aged men or maybe the adolescents, you have to decide. 

For instance, an anti-ageing cream’s audience is going to be over 25, it could be the working women who stress too much at work that they have developed wrinkles at 30 or it could be the stay-at-home mothers who have very little time for skin care or both. If your website and its design effectively justifies their needs, a conversion is almost guaranteed, and that is all we want. 

Make the website responsive to everyone 

Today, websites are not only accessed through laptops and desktops, people do it from any device that has a screen and an internet connection, especially smartphones. So, seeing something like “this website is incompatible with your device” is not going to generate many leads for you.

Mobile friendliness is crucial for websites, they need to be made responsive to reconfigure itself to the screen size of the device, which is browsing it.

Focus on the software

Up until now, we have covered everything that could be redesigned on your site, now let us talk about the makeup of your website a little as well. A Content Management Software or a CMS is the way to go here. From developing the site to publishing regular content on it, the CMS would do just about anything you could want. Drupal, one of the leading CMSs in the market share, can be a magnificent choice. Be it government websites or private companies or even sports stars wanting to create their online space, Drupal provides for all.

Journalism websites need a lot more flexibility in content than any other category. Since Drupal is the embodiment of flexibility and provides just the right set of core features and contributed modules, choosing it becomes a no brainer. Earth Journalism Network’s website is the prime example of remarkable improvements that are possible with website redesigning. OpenSense Labs Team migrated the old site, which was running on a Python-based CMS, to Drupal 8. This ultimately proved to be a remarkable move as creating and managing content turned out to be super efficacious. Access the full case study of Earth Journalism Network to know more.

The Website Redesigning Approach: ESR

The web would keep on evolving at a pace that is faster than your redesigning abilities. You might think that is a bad omen, but it isn’t, not completely. Yes, the web keeps on evolving, but its evolution does not mean that your website would become completely obsolete. There would be a lot of things still working for you since the last redesign and the things that do not, you can simply update them.

All of this becomes a walk in the park with Evolutionary Site Redesign or ESR. This is an approach that continually tests certain problematic areas of your websites, giving you feedback about their performance.

A line graph is showing the correct strategy to be implemented during website redesign.Source: Wider Funnel

It is not only a faster approach to redesigning, but also becomes extremely helpful in reducing the risk as you would be making incremental improvements consistently, instead of a complete overhaul. The result is a better user experience for your visitors and everybody stays happy. That is why ESR is often regarded as the right website redesign approach.

The Mistakes to Avoid 

Now that you know all about things that you need to address, it is now time to know what to avoid in the website redesign strategy. These are mistakes that are more common than you would think and these mistakes can become quite costly for your website. 

Nondescript scope 

Scope of work, that is both doable and well-defined, sets the pace for any project. It is like a roadmap that will tell you what the next destination is and whether to take a right or a left turn to reach there without much hassle. Taking on a website redesign project is a huge step, so you have to clear, explicitly clear, as to what you want to do and how it would be done. 

The scope also lays emphasis on accountability, as it clearly allocates duties to be done by members of the team. So, when something doesn’t happen, you would know where to point the finger. Without a well-defined scope, the smooth sailing of the redesign project is not possible.

Not emphasising on the content 

The content on your website is probably one of its most important aspects. Think of it like the voice of your website, since it clearly speaks for you and your brand. So, ensuring that the content is well-written, engaging, simplified and SEO friendly at the same time should be a priority. You can hire professionals to write it for you. The thing is a high quality content would need time from your end, so not getting a head start on it is not the way to go.

Biting off more than you can chew 

Another mistake that often happens in a redesign project is that the owners overreach. They try to do everything possible to make the website better than the existing. Although this should not be a mistake, the timeline of the project may disagree. The completion of a project in its designated time is what makes it worthwhile. So, when you keep on adding additional tasks on an ongoing scope, you will just be stretching yourself for time and the project would only get delayed. 

This does not mean that you cannot add too many features in your website, you certainly can, but you should try adding those in phases. Doing everything at  once and doing one thing at a time is different and let me tell you, the latter almost always succeeds.

Compromising on one aspect for the other 

Another pitfall that is experienced in the redesigning projects is the compromise. In the race to finish a project, the developers start compromising on one aspect of the website for the other, and this disrupts the overall redesign. For instance, you cannot just focus on the aesthetics of your website, its functionality and technical aspects need equal consideration. The user might come to your website and even stay awhile because of the aesthetics, but if your website won’t deliver in terms of functionality no one would stay longer than awhile and conversions would seem far fetched.

The Right Partner for Website Redesign

Like I have already mentioned a few times, website redesigning is a colossal undertaking, so it needs the support of a team to make it successful. Many websites have taken up the redesigning endeavour on their own, but only because they have a comprehensive team that can perform all the redesigning duties including a developer, a designer, a marketing strategist, an SEO expert, copywriters, to name a few. If you have such a team, take up the redesigning yourself. If not, you should consider a website redesign agency

Here are a few pointers to help you;

What is its niche?

Before checking anything else, you have to find out which area does the organisation excel at. Is it an ad agency, marketing agency or does it specialise in technical aspects? Knowing all of this will help narrow down your search for the right partner, since the speciality of the agency has to be in accordance with your business. A high-profile public enterprise can go for an ad agency that deals with celebrities.

What approach does the agency use?

The agency’s approach towards tackling redesigning is very crucial, because that will set the pace for the website’s future growth. So, if an agency is focusing on enhancing  the user experience as its core, you should hire it without a second thought.

How good is it performance-wise?

Ensuring that the redesigning agency has had a good track-record in its past projects is also necessary. To do so, you can simply check the testimonials on their website. This way you can predict how well it would tackle your redesigning.

Can it perform an audit?

An audit is very valuable when taking up redesigning a website. So, you must go for an agency that would perform a thorough audit, both for the content and the architecture of the website, before working on the changes. 

Do they know your target audience?

A website redesign won’t do you much good, if it is not targeted at your potential customers and compelling them to buy from you. So, an agency that has knowledge or will acquire the knowledge about your target customers is going to be the right fit for you.

How extensive are its services?

Lastly, the range of services a redesign agency provides will be the last stepping stone in your decision. It cannot just provide a marketing strategy or just implement the SEO techniques, the services have to be all inclusive. 

All of these questions need to be addressed before you take up a partnership with a redesigning agency. 

Website Redesigning- Not a One-Time Gig 

Now, you are all set to make the redesigning decision. However, I would like you to know one more thing. Website redesign never ends, it is a perpetual project that would keep returning every few years or as early as your resources allow. Trends keep changing in the virtual world, and your website must change with them, barring the fact that it is responsive or not. If you have a bigger establishment with resources in abundance, you can redesign at least once a year. On the other hand, if resources are scarce, you can wait as long as half a decade, provided that your website is responsive.

Redesigning is similar to changing your car, you have to do it every few years. Driving the same car for a decade would not seem appealing or a sign or growth, what do you think?

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web