OVERVIEW/SUMMARY

The goal of this survey was to better understand the preferences of organisations and individuals who are already building decoupled applications in order to help inform the decisions we make going forward. The survey was executed using Survey Monkey and was promoted primarily via existing Drupal developer channels. The survey ran for 2 weeks, and received a total of 133 responses.

Below are some of our initial findings from looking at the results. And we anticipate coming back to this data later to help better understand the needs of existing decoupled application developers.

You can learn more about the Decoupled Menus Initiative, and come say hi on Slack in #decoupled-menus-initiative.

ANALYSIS

Q1: How many years have you been building decoupled applications?

Caption: Question 1 - Graph showing count of Responses

Caption: Question 1 - Table showing count of responses

These results show a significant amount of users in the 1-3 year range, this is somewhat expected given how the growth of frameworks like Vue, React, has accelerated in the past few years. A notable amount of users have been building decoupled sites for longer than 3 years, perhaps a sign that we have almost 30% of our responses being early adopters?

Q2: Which CMSs do you use?

Caption: Question 2 - Graph showing CMS usage

Caption: Question 2 - Table showing CMS usage responses

The overwhelming number of responses are Drupal users. This was a multiple choice question, and there were only 9 respondents who did not list Drupal. Given how the survey was marketed largely to our existing networks this isn’t surprising. It is worth remembering, however, that these results are going to be heavily skewed towards the thoughts of existing Drupal users.

In the future we need to find more ways to engage with users outside the Drupal bubble if we want to learn what is required to make Drupal an attractive platform for them.

Q3: Which JS frameworks do you use?

Caption: Question 3 - Graph showing which JS frameworks are being used

Caption: Question 3 - Table showing which JS frameworks are being used

It is clear that React is certainly favored among out participants, with Vue being a fairly close second. Other frameworks do not have a lot of representation. These results indicate that we should make efforts to ensure that we cater to both React and Vue users, with other frameworks being secondary concerns in terms of support?

According to the 2020 State of JS survey 80% of JavaScript developers use React, and 49% use Vue. That’s a much larger difference than what we see in our data. And maybe indicates that there’s a stronger attraction to Vue amongst Drupal users than in the general JS world. Which may be worth noting when making decisions using these numbers. Also, Angular has 56% usage, higher than Vue, in the State of JS survey but only 17% amongst Drupal users.

The Next/Nuxt frameworks are used by ~30% of React/Vue developers. This is something we should be aware of. And at least ensure that our solutions are compatible with these tools with minimal fuss.

Q4: Which JS (nodejs) tooling do you use?
 

Caption: Question 4 - Graph showing which JS (nodejs) tooling are being used

Caption: Question 4 - Table showing which JS (nodejs) tooling are being used

NPM is the most widely used nodejs tool which isn’t too shocking. We didn’t have an option for Yarn, but it was written in the other response 10 times. It is probably safe to say that a majority of our user base still prefer to use NPM as their package manager. Webpack and Gulp use should not be ignored as it looks like these are the two most prevalent node build tools.

This lines up with the broader JavaScript ecosystem where the State of JS data indicates that both NPM and Webpack are nearly ubiquitous among JavaScript developers.

One thing this data doesn’t tell us is what tooling people *want* to use. And it may be worth trying to dig into that more. Especially if the goal is to be an attractive platform for developers. We should be aware of both what tools are most common, but also what tools people prefer.

Q5: Which API technologies do you use?

Caption: Question 5: Graph showing which API technologies are being used

Caption: Question 5: Table showing which API technologies are being used

A healthy mix of API technologies are being used here, but again it may be worth noting that a lot of our Drupal users are using JSON:API by necessity as it is the primary way Drupal is used as a REST API. We shouldn’t ignore that over 50% of respondents are using GraphQL, this may or may not be in the context of Drupal, but it does signify that there may be a desire to use this for retrieving decoupled data?

Q6: Which data fields or properties do you believe are essential to render a menu component?

Caption: Question 6 - Table showing responses of which data fields or properties are essential to render a menu component

A surprising result here is that the Active Trail is not a priority to our users. Menu Hierarchy and Multilingual being the most important means that we need to ensure that we are able to cleanly deliver the menu tree data, along with appropriate translation data.

Q7: What is the best experience you have had when working with menu responses?

This was an open-ended question and received 42 write in answers.

There was some interest in Gatsby. Some narratives included:

A recent menu integration with Gatsby worked well - we accessed menu data via gatsby-source-Drupal and then exported these components using webpack along with their data. This allowed us to use the exact same React footer in pages rendered by Drupal and Pages rendered by Gatsby.

Gatsby, with the `activeMenuClass` and `partiallyActive` features, makes it soooo easy to have an active menu and active trail.

We saw some interest in GraphQL, with responses like: 

On the backend we used the GraphQL Drupal module and declared a schema, following the documentation (https://drupal- graphql .gitbook.io/graphql/queries/menus) On the frontend, using Apollo we would just query the menu and then render that into a custom component.

Using the graphql Drupal module with Next.js. The only thing that we had to do was made a query by menu name to Drupal, the response was an array of items of type { link, label, children: [] }

Writing a custom GraphQL resolver for Drupal 9 that returns exactly what I need.

Which highlights that a handful of respondents have been reaching for GraphQL in order to provide a simple data -> frontend flow.

The answers to this question highlight that right now, in order to manage menus using Drupal in a decoupled scenario, people are invariably crafting their own solutions. That people have been able to make things work. And that at best the experience has been fine, and at worst it’s frustrating. People have used a range of approaches including; Using data available in the existing JSON:API output, custom GraphQL resolvers, putting the content of a menu into a custom block and consuming that block, using the jsonapi_menu_items module in contrib, and hard-coding menus into the front-end, and more.

This indicates that there is definite potential for standardization and providing a built-in solution so that people don’t have to reinvent the wheel with every new project. And, some people mentioned having already started work on their own reusable solutions to this problem.

Another common thread in these answers is that most people’s custom solutions involved creating the data in Drupal in some way (custom block entity, GraphQL resolver, jsonapi_menu_links) so that the front-end application could consume the entire menu in a single response that contained titles, links, and hierarchy. This desire to be able to construct a single menu object in the UI was also mentioned in answers where people talked about non-Drupal menu building experiences.

Netlify Menus, set a collection of type Menu, and edit the links. That's the easiest way. For Drupal is not a big deal but separated fragments have to be done in order to pull just those entities.

Q8: How do you use API data to build a Menu Component?

Caption: Question 8 - Table showing responses of how do you use API data to build a Menu Component

Early analysis of the results, we found this to be a trend which has held. This is quite surprising, given the bounty of available frameworks out there. But it perhaps illustrates either the challenging nature of adapting drupal menu data to a framework, or the demands of clients that need more flexibility than frameworks are able to provide?

Q9: What expectations do you have for Documentation, when working with a headless CMS?

Caption: Question 9 - Table showing responses of expectations for Documentation, when working with a headless CMS

We think that quality documentation will be an important part of improving the experience for JavaScript developers consuming data from Drupal APIs. And are already planning on making that a focal point of the work we do in this initiative. Based on the results we clearly need to make sure that code snippets and a getting started guide are part of whatever we create.

Based on the result of question 3, it seems that we should also attempt to provide these code snippets in both React and Vue variations.

Q10: Describe the biggest challenges you encounter when building a project with Decoupled/Headless CMS

This was an open ended question and received 63 responses.
What appears to stand out here are the words Drupal, data, menu, and routing. This probably indicates that the data and routing are challenges that we will want to make sure we address. Drupal and menu are terms that are probably used in a majority of responses without negative or positive context, per se. We could dive into some of the direct response texts in order to attain a better idea of the context in which these terms are being used.

CONCLUSION

The survey results indicate that people view code snippets, and a getting started guide, as a critical part of the documentation we produce. We should try and further define what awesome examples of these look like so we know what to aim for.

We’re aware that the results of this survey for the most part only reflect people who are already engaged with the Drupal community. Since part of this initiative’s goals are to help make Drupal a more attractive platform for JavaScript developers who are not already part of the Drupal community we’ll have to make sure and do the work of connecting with those people. It’s important that their voices are heard and that we don’t build solutions in an echo chamber.