Drupal

OpenSense Labs: Run to Glory: The Drupal Effect on High Performance Websites

Planet Drupal - 20 July 2018 - 4:06am
Run to Glory: The Drupal Effect on High Performance Websites Shankar Fri, 07/20/2018 - 16:36

Usain Bolt, in his last appearance at the World Track and Field Championships in 2017, stood third by a narrow defeat in the 100m race leaving behind a yawning gulf. Bolt finished the race just a hundredth of a second later than his fellow competitors.

Every (nano)second counts!


Such is the importance of speed that even a three-time Olympic gold medallist, Usain Bolt, had to bear the brunt of those nanoseconds. Someone might ask “How do I get started learning about web performance?

Visualise that it is the Mega Book Sale Day and the bookworms are thronging the best performing online stores that are selling the books of renowned authors. Coping with such a colossal turn-up, a site with much faster page load speed would be preferred over the ones that are a bit sluggish. Drupal offers a superb platform for an effective website performance optimisation thereby making it faster and user-friendly.

The Significance of Website Performance Optimisation

Web performance optimisation involves monitoring the performance of web application analysing and assessing it, and identifying the best practices to improve it.

Web applications are a combination of server-side and client-side code. To improve the web performance, both the sides need to be optimised.

The client-side optimisation relates to the initial page load time, JavaScript that runs in the browser, downloading all of the resources etc. that are seen in the web browser.

The server-side optimisation relates to database queries and other application dependencies to check how long it takes to run on the server for executing requests.

Performance optimisation is significant because of the following factors:

User retention

BBC found that they are losing out of 10% of users for every extra second their website took to load. Also, DoubleClick by Google found that if the web page took more than 3 seconds to load, 53% of mobile site visitors tend to abandon the page.

 

We all strive to make our users engage in a meaningful interaction with what we have built for the web.

So, if it is an online store, you would like to see a prospective audience turning into buyers. Or if it is a social networking web application, you would want your online visitors to get ensconced in an arresting interaction with one another. High performing sites play a vital role in engaging and retaining users.

An increase in user retention by 5% can result in increased profits by up to 95%.

It costs 5 to 25 times more to attract new customers. So, even a 5% enhancement in customer retention can lead to increased profits of 25%-95%.

By redesigning their web pages, Pinterest combated a 40% reduction in perceived wait times and witnessed a 15% increase in their search engine traffic and sign-ups.

COOK, a provider of high-quality frozen meals, was able to address the average page load time and cut it down by 850 milliseconds which resulted in 7% in conversions, 10% increase in pages per session and 7% decrease in bounce rate.

Improved Conversions

User retention ultimately leads to better conversion rates. Slow sites can have huge repercussions on the business revenues. Better performance of sites can be highly profitable to shore up revenues.

Source: Hubspot

According to 2016 Q2 Mobile Insights Report by Mobify, 1.11% increase in session-based conversion was seen for every 100ms decrease in homepage load speed. Moreover, a 1.55% increase in session-based conversion was noticed for every 100ms decrease in checkout page load time. The outcome was an increase in the average annual revenue by approximately $530,000.

Also, AutoAnything revved up their sales by 12-13% after decreasing their page load time by half.

User experience

When sites ship tons of code, underwhelming performance persists as the browsers chew through megabytes of it on snail-paced networks. 

Source: Impactbnd

Even the devices with limited processing power and memory can find it hard to cope up with the modest amount of unoptimised code. With poor performance taking centre stage, application responsiveness and availability diminishes.

Better optimised code lead to high functioning and better-performing sites which in return alleviate the digital user experience.

Strategising the web performance

Formulation of strategies to improve web performance can be done in two ways:

Bottom-up strategy

Also known as performance-by-design, the bottom-up strategy is the preferred approach to integrate performance as a core development principle. In this strategy, the performance optimisation principles are framed, applied and maintained. This is done right from the application design phase. 

The key stages that are involved in this approach are stated below:

  • Performance principles are laid out.
  • The key pages/transactions are identified, optimised accordingly, and then performance principles are executed.
  • Performance SLAs (Service Level Agreement) are monitored and maintained.

Here's a chart by Infosys which explains it best: 

Key stages involved in bottom-up strategyTop-down strategy

If an existing application needs to be optimised for performance, top-down strategy comes into play. This is a preferred option only when the legacy applications are being optimised for high performance. Also, this is not cost effective and the optimisation options are limited.

Steps involved in this strategy are as follows:

  1. Factors that are contributing to the page performance are assessed using tools like PageSpeed Insights, WebPageTest etc.
  2. Activities that would lead to maximum performance improvements are optimised.
  3. Other optimisations with subsequent releases are iteratively implemented.

In addition to these strategies, one must consider an important methodology called ‘Performance Budgeting’. It means setting a performance threshold that you aim to stay within. You can safeguard your site speed and detect any regression in the performance by setting up a performance budget to ensure continual eye on performance.

This is how we do it!

Expected load time and Google page speed score, as shown below, is the core of our perpetual and iterative development process.

The above chart shows that, while applying performance budgeting methodology, we take note of:

  1. Average load time of 2 seconds or less
  2. Defined maximum limit on page size and number of HTTP requests
  3. Verification of all server site tuning for an efficient and responsive site
  4. Google page speed performance grade of above 90
  5. Implementing performance optimisation
How to Speed up My Drupal Website Performance?

How to speed up my Drupal website performance? Drupal is loaded with an enormous amount of features which, when implemented smartly, can lead to superfast page loads. There are several techniques to make your website faster by leveraging the amazing features of Drupal.

Keeping your site and modules updated

Outmoded modules can deter your efforts in speeding up your website. Thus, it is important to update every module enabled on your Drupal site.

Uninstalling unused modules

Like those outdated modules, it is significant to keep a tab on least used or no longer used modules. The number of Drupal modules installed on the site is directly proportional to the time taken for code execution which affects page load time. Uninstalling unwanted modules can alleviate execution time.

Moreover disabling the modules also adds to the execution time of the code. So, a complete removal by uninstalling the unused modules can speed up the Drupal site.

Optimising Cache

Optimisation of native cache system ensures that all the web page components are stored in an easily accessible location after a user visits your site for the very time. So, whenever the user visits your site again, the page elements are loaded from the cache which leads to increased page load speed.

Drupal has the provision of advanced caching with a great set of modules:

  • Internal Page Cache module helps in caching the web pages for anonymous users to increase the speed for subsequent users.
     
  • Dynamic Page Cache module caches web pages for the anonymous and authenticated users and is recommended for the websites of all screen sizes.
     
  • BigPipe module allows your users to quickly see the unchanged, cacheable page elements while the personalised content is exhibited next. This technology was inspired by Facebook. Drupal 8’s much improved render pipeline and render API is of huge help.
     
  • Redis module helps in integrating Drupal with Redis key-value store thereby providing a robust cache system for static pages.
     
  • Varnish module lets you integrate Drupal sites with an advanced and fast reverse-proxy system - Varnish cache -  to serve static files and unknown page-views quicker and at high volumes.
Optimising database

Website coding is not the sole thing that can be optimised. Optimising database by regularly cleaning up the data and removing the unwanted piece of information.

Memcache API and Integration module, help in the integration of Drupal and Memcached. It stores your data in active memory for a limited period of time thereby making it faster to access. 

So, instead of making queries to the database constantly, the information is readily available. Such a system also works on the shared web hosting plans.

Incorporating a Content Delivery Network (CDN)

Components like CSS, JavaScript and media are hosted by CDN and served to the online visitors from the nearest location. This can help in mitigating the page load time by rapidly delivering web page components.

Drupal module, CDN, helps in the integration of Content Delivery Network for Drupal websites. It changes the file URLs so that files like CSS, JavaScripts, images, videos, and fonts are downloaded from the CDN instead of your web server.

Optimising bandwidth

Aggregating all CSS and JavaScript files to make them load together is what bandwidth optimisation refers to. Such a parallel processing ensures that all the page elements can be seen by the users almost immediately.

Optimising images

Drupal 8 core is loaded with image optimisation feature to set the compression ratio of the images and fine-tune the page performance.

Moreover, the size of the images for screen sizes of different devices can be optimised in Drupal 8 to enhance the page load speed.

Handling 404 errors

Whenever something on the website breaks to cause a 404 error, it can lead to sluggishness. For instance, a failed image can damage the performance of the site. Drupal 8 provides a module called Fast 404 which utilises the resources better and whitelists files and verifies pathways of problem.

Managing the use of CSS and JavaScript

CSS and JavaScript provide wonderful methods for customisation and flexibility. But, too much of good things can be troublesome for your websites. Avoiding excessive use of CSS files and JavaScript use and keeping the code to a minimum can improve performance.

Advanced CSS/JS Aggregation, Drupal module, can help in keeping a tab of your front-end performance by aggregating CSS and JavaScript files to improve speed.

Using lazy loading

Lazy or on-demand loading is a perfect way to optimise your site’s performance. In this method, you split your code at logical breakpoints and then load it once the user has done something that requires a new block of code.

Basically, in traditional websites, all the images and content are preloaded into the web browser when someone accesses the site. Lazy loading loads these elements as soon as a user scrolls to view a content.

Blazy, Drupal module, provides the functionalities of lazy loading and multi-serving the images to save bandwidth and server requests.

Better web hosting

It is of consummate importance that, while implementing every possible tips and trick and utilising the Drupal’s amazing features, you chose the best web hosting provider that will decide your site’s ultimate speed, stability and security.

Case Study

The Drupal website of the Farm Journal’s MILK was optimised for high performance and better search engine rankings with a help of carefully drafted audit report by Opensense Labs.

In this section, we will focus on how we used our Drupal expertise to resolve the performance issues.

Project highlights

Previously segregated CSS and JS files cached separately which escalated the page load time. We aggregated all these files and put them in one place which assuaged the page load time.

Moreover, we used Advanced CSS/JS Aggregation Drupal module to minify CSS, JS and HTML and reduce load time.

In addition to these, we enabled Redis, used as a database, cache and message broker, so that it can be used as the backend instead of MySQL. This allowed cached items to be retrieved swiftly and improved performance.

Project outcome

On testing the performance metrics on tools like PageSpeed Insights and Pingdom, we witnessed significant improvement.

PageSpeed Insights

  • Result on handheld devices
Pre-implementation (Live Instance)

 

Post-implementation (Live Instance)

 

  • Result on Desktop
Pre-implementation (Live Instance)

 

Post-implementation (Live Instance)

 

Pingdom

Pre-implementation Pingdom Score (Live Environment)

 

Post-implementation Pingdom Score (Live Environment)

 

Conclusion

Speed can be the determining factor in the amount of time an online user spends on your website. It’s important that you remove the sluggishness from your website and inculcate betterments in its performance. Drupal 8 can help by incorporating wonderful features to make your site a high performing space.

Feel free to reach us at hello@opensenselabs.com for developing a high performing Drupal website.

blog banner blog image Performance Optimisation Web Performance Performance Budgeting Website Performance Optimisation User Retention Conversion Rate User experience Page Load Speed Page Load time Blog Type Articles Is it a good read ? On
Categories: Drupal

Drop Guard: Multi User - Invite your team to Drop Guard!

Planet Drupal - 20 July 2018 - 4:00am
Multi User - Invite your team to Drop Guard! We happily announce our Multi User - Invitations feature! Our users needed an option to add more team members with tailored access rights for a specific project.  So we created the “Invitations” section in our menu bar on the left. By entering this page, you will be able to invite other team members or view the invitation for yourself. You can assign specific projects to a team member, be it developer, support manager or project manager; as well as you can give your customer read access to the customer’s project without exposing your other projects. This access policy feature provides new possibilities for an open and understandable workflow with Drop Guard.  Drupal Planet Drupal announcements Business
Categories: Drupal

Drop Guard: Modules overview - get detailed information about all modules

Planet Drupal - 20 July 2018 - 3:34am
Modules overview - get detailed information about all modules What modules do I use? How often are they used in my project? In which projects? Which version exists? Is it the same version as on drupal.org? Might a specific module be a threat for my project(s)? These and many more questions will be answered within one click on our “Modules overview page” on the left in the menu bar. Check out this short post to learn more about our new feature! Among other reasons, this feature was requested by our users as they also want to track whether a module is quite relevant for a project or less critical within an update process. Drupal Planet Drupal features announcements
Categories: Drupal

Drop Guard: We said "yes"! Our founding of App Guard GmbH

Planet Drupal - 20 July 2018 - 3:30am
We said "yes"! Our founding of App Guard GmbH What happened?  We founded an independent company, including the Drop Guard service! Learn more about the App Guard GmbH journey so far in this announcement post. But first, where did we came from?  Drop Guard was built by the German Drupal company Bright Solutions in 2014, after the idea was born to optimize the internal update process as much as possible - no more wasted time on updates, no fear of Drupalgeddon, no annoying update tasks. 
The platform service was optimized and adapted continuously besides other projects of the company, until Manuel Pistner, CEO of Bright Solutions, decided to form a team for this project, that already counted important customers. 
Drupal Planet Drupal Business announcements
Categories: Drupal

Santa

New Drupal Modules - 20 July 2018 - 2:36am
Categories: Drupal

Advanced number format(ter/s) - i18n & rounding

New Drupal Modules - 20 July 2018 - 1:32am

Provides advanced number formatting and rounding options for

  • Float
  • Integer

fields.

Integer would also work but doesn't make sense from my point of view, because the core formatters already provide everything needed for integers, I think. No rounding is needed.

Categories: Drupal

SMSFactor for SMS Framework

New Drupal Modules - 20 July 2018 - 1:27am

This module provides integration between SMSFactor and SMS Framework.

Maintainers of this module are not affiliated with the SMSFactor company.

Installation composer require drupal/sms composer require drupal/sms_smsfactor
Categories: Drupal

OVH for SMS Framework

New Drupal Modules - 20 July 2018 - 1:26am

This module provides integration between OVH and SMS Framework.

Maintainers of this module are not affiliated with the OVH Group.

Installation composer require drupal/sms composer require drupal/sms_ovh
Categories: Drupal

Appnovation Technologies: Expert Corner: Workspace Upgrade Path

Planet Drupal - 20 July 2018 - 12:00am
Expert Corner: Workspace Upgrade Path Millwood's Musings We've taken some time recently to discuss how we're going to handle the upgrade from the Workspace contrib module to the Workspace core module, once it's released. In our setup we have around 20 sites, each with 4 (or more) environments, all with Workspace installed, syncing content between each environments (and sometimes b...
Categories: Drupal

Moha

New Drupal Modules - 19 July 2018 - 11:39pm

Moha module helps developer create module easily.

Categories: Drupal

Timestamp Range

New Drupal Modules - 19 July 2018 - 7:02pm

The timestamp range field what stores start and end datetime values as unix timestamps.
The work is in progress.

Categories: Drupal

Agiledrop.com Blog: AGILEDROP: Our blog posts from June

Planet Drupal - 19 July 2018 - 5:38pm
You have already seen what Drupal blogs were trending in the previous month, and now it is time to look at all our blog post we wrote. Here are the blog topics we covered in June.   The first blog post was Drupal and the Internet of Things. Unless you’ve been living under the rock these past few years, you might have heard of the term ‘The Internet of Things’. If you’ve always wondered what the Internet of Things is and you know what Drupal is, you should read this blog post.   The second was an Introduction to Drupal Commerce. Drupal and Commerce. These are two words that aren’t usually… READ MORE
Categories: Drupal

Drupal blog: How Drupal continues to evolve towards an API-first platform

Planet Drupal - 19 July 2018 - 12:10pm

It's been 12 months since my last progress report on Drupal core's API-first initiative. Over the past year, we've made a lot of important progress, so I wanted to provide another update.

Two and a half years ago, we shipped Drupal 8.0 with a built-in REST API. It marked the start of Drupal's evolution to an API-first platform. Since then, each of the five new releases of Drupal 8 introduced significant web service API improvements.

While I was an early advocate for adding web services to Drupal 8 five years ago, I'm even more certain about it today. Important market trends endorse this strategy, including integration with other technology solutions, the proliferation of new devices and digital channels, the growing adoption of JavaScript frameworks, and more.

In fact, I believe that this functionality is so crucial to the success of Drupal, that for several years now, Acquia has sponsored one or more full-time software developers to contribute to Drupal's web service APIs, in addition to funding different community contributors. Today, two Acquia developers work on Drupal web service APIs full time.

Drupal core's REST API

While Drupal 8.0 shipped with a basic REST API, the community has worked hard to improve its capabilities, robustness and test coverage. Drupal 8.5 shipped 5 months ago and included new REST API features and significant improvements. Drupal 8.6 will ship in September with a new batch of improvements.

One Drupal 8.6 improvement is the move of the API-first code to the individual modules, instead of the REST module providing it on their behalf. This might not seem like a significant change, but it is. In the long term, all Drupal modules should ship with web service APIs rather than depending on a central API module to provide their APIs — that forces them to consider the impact on REST API clients when making changes.

Another improvement we've made to the REST API in Drupal 8.6 is support for file uploads. If you want to understand how much thought and care went into REST support for file uploads, check out Wim Leers' blog post: API-first Drupal: file uploads!. It's hard work to make file uploads secure, support large files, optimize for performance, and provide a good developer experience.

JSON API

Adopting the JSON API module into core is important because JSON API is increasingly common in the JavaScript community.

We had originally planned to add JSON API to Drupal 8.3, which didn't happen. When that plan was originally conceived, we were only beginning to discover the extent to which Drupal's Routing, Entity, Field and Typed Data subsystems were insufficiently prepared for an API-first world. It's taken until the end of 2017 to prepare and solidify those foundational subsystems.

The same shortcomings that prevented the REST API to mature also manifested themselves in JSON API, GraphQL and other API-first modules. Properly solving them at the root rather than adding workarounds takes time. However, this approach will make for a stronger API-first ecosystem and increasingly faster progress!

Despite the delay, the JSON API team has been making incredible strides. In just the last six months, they have released 15 versions of their module. They have delivered improvements at a breathtaking pace, including comprehensive test coverage, better compliance with the JSON API specification, and numerous stability improvements.

The Drupal community has been eager for these improvements, and the usage of the JSON API module has grown 50% in the first half of 2018. The fact that module usage has increased while the total number of open issues has gone down is proof that the JSON API module has become stable and mature.

As excited as I am about this growth in adoption, the rapid pace of development, and the maturity of the JSON API module, we have decided not to add JSON API as an experimental module to Drupal 8.6. Instead, we plan to commit it to Drupal core early in the Drupal 8.7 development cycle and ship it as stable in Drupal 8.7.

GraphQL

For more than two years I've advocated that we consider adding GraphQL to Drupal core.

While core committers and core contributors haven't made GraphQL a priority yet, a lot of great progress has been made on the contributed GraphQL module, which has been getting closer to its first stable release. Despite not having a stable release, its adoption has grown an impressive 200% in the first six months of 2018 (though its usage is still measured in the hundreds of sites rather than thousands).

I'm also excited that the GraphQL specification has finally seen a new edition that is no longer encumbered by licensing concerns. This is great news for the Open Source community, and can only benefit GraphQL's adoption.

Admittedly, I don't know yet if the GraphQL module maintainers are on board with my recommendation to add GraphQL to core. We purposely postponed these conversations until we stabilized the REST API and added JSON API support. I'd still love to see the GraphQL module added to a future release of Drupal 8. Regardless of what we decide, GraphQL is an important component to an API-first Drupal, and I'm excited about its progress.

OAuth 2.0

A web services API update would not be complete without touching on the topic of authentication. Last year, I explained how the OAuth 2.0 module would be another logical addition to Drupal core.

Since then, the OAuth 2.0 module was revised to exclude its own OAuth 2.0 implementation, and to adopt The PHP League's OAuth 2.0 Server instead. That implementation is widely used, with over 5 million installs. Instead of having a separate Drupal-specific implementation that we have to maintain, we can leverage a de facto standard implementation maintained by others.

API-first ecosystem

While I've personally been most focused on the REST API and JSON API work, with GraphQL a close second, it's also encouraging to see that many other API-first modules are being developed:

  • OpenAPI, for standards-based API documentation, now at beta 1
  • JSON API Extras, for shaping JSON API to your site's specific needs (aliasing fields, removing fields, etc)
  • JSON-RPC, for help with executing common Drupal site administration actions, for example clearing the cache
  • … and many more
Conclusion

Hopefully, you are as excited for the upcoming release of Drupal 8.6 as I am, and all of the web service improvements that it will bring. I am very thankful for all of the contributions that have been made in our continued efforts to make Drupal API-first, and for the incredible momentum these projects and initiatives have achieved.

Special thanks to Wim Leers (Acquia) and Gabe Sullice (Acquia) for contributions to this blog post and to Mark Winberry (Acquia) and Jeff Beeman (Acquia) for their feedback during the writing process.

Categories: Drupal

Lullabot: Introducing Contenta JS

Planet Drupal - 19 July 2018 - 8:37am

Though it seems like yesterday, Contenta CMS got the first stable release more than a year ago. In the meantime, the Contenta CMS team started using Media in core; improved Open API support; provided several fixes for the Schemata module; wrote and introduced JSON RPC; and made plans to transition to the Umami content model from Drupal core. A lot has happened behind the scenes. I’m inspired to hear of each new instance where Contenta CMS is being used both out-of-the-box and as part of a custom decoupled Drupal architecture. Both use cases were primary goals for the project. In many cases, Drupal, and hence Contenta CMS, is only part of the back-end. Most decoupled projects require a nodejs back-end proxy to sit between the various front-end consumers and Drupal. That is why we started working on a nodejs starter kit for your decoupled Drupal projects. We call this Contenta JS.

Until now, each agency had their own nodejs back-end template that they used and evolved in every project. There has not been much collaboration in this space. Contenta JS is meant to bring consistency and collaboration—a set of common practices so agencies can focus on creating the best software possible with nodejs, just like we do with Drupal. Through this collaboration, we will be able to get features that we need in every project, for free. Today Contenta JS already comes with many of these features:

  • Automatic integration with the API exposed by your Contenta CMS install. Just provide the URL of the site and everything is taken care of for you.
    • JSON API integration.
    • JSON RPC integration.
    • Subrequests integration.
    • Open API integration.
  • Multi-threaded nodejs server that takes advantage of all the cores of the server’s CPU.
  • A Subrequests server for request aggregation. Learn more about subrequests.
  • A Redis integration via the optional @contentacms/redis.
  • Type safe development environment using Flow.
  • Configurable CORS.
undefined

Watch the introduction video for Contenta JS (6 minutes).

Videos require iframe browser support.

Combining the community’s efforts, we can come up with new modules that do things like React server-side rendering with one command, or a Drupal API customizer, or aggregate multiple services in a pluggable way, etc.

Join the #contenta Slack channel if this is something you are passionate about and want to collaborate on it. You can also create an issue (or a PR!) in the GitHub project. Together, we can make a holistic decoupled Drupal backend from start to end.

Originally published at humanbits.es on July 16, 2018.

Categories: Drupal

Navigation Blocks

New Drupal Modules - 19 July 2018 - 6:18am

Provides some navigational tools, like a generic back button that, given a certain entity type, bundle or URL, takes the user back to a preferred location.

Categories: Drupal

Better Page Not Found

New Drupal Modules - 19 July 2018 - 6:12am

This module automatically improves the layout of 404 (page not found)
and 401 and 402 (not authorized) pages. If the current page is an 404
(or 401 or 402) page then it replaces the page content with a themed
message.
It does not replace other page items, so the error page will
still show your header and footer, and thus have your site styling intact.

The 404 (page not found) page will show following message:
'The requested page could not be found.' (this is translatable)

Categories: Drupal

Unpublished Permissions

New Drupal Modules - 19 July 2018 - 5:23am

Adds permissions to view, edit and delete unpublished content.

Usage
  1. Navigate to /admin/people/permissions
  2. Adds the permissions to the appropriate role
Categories: Drupal

Dries Buytaert: How Drupal continues to evolve towards an API-first platform

Planet Drupal - 19 July 2018 - 4:06am

It's been 12 months since my last progress report on Drupal core's API-first initiative. Over the past year, we've made a lot of important progress, so I wanted to provide another update.

Two and a half years ago, we shipped Drupal 8.0 with a built-in REST API. It marked the start of Drupal's evolution to an API-first platform. Since then, each of the five new releases of Drupal 8 introduced significant web service API improvements.

While I was an early advocate for adding web services to Drupal 8 five years ago, I'm even more certain about it today. Important market trends endorse this strategy, including integration with other technology solutions, the proliferation of new devices and digital channels, the growing adoption of JavaScript frameworks, and more.

In fact, I believe that this functionality is so crucial to the success of Drupal, that for several years now, Acquia has sponsored one or more full-time software developers to contribute to Drupal's web service APIs, in addition to funding different community contributors. Today, two Acquia developers work on Drupal web service APIs full time.

Drupal core's REST API

While Drupal 8.0 shipped with a basic REST API, the community has worked hard to improve its capabilities, robustness and test coverage. Drupal 8.5 shipped 5 months ago and included new REST API features and significant improvements. Drupal 8.6 will ship in September with a new batch of improvements.

One Drupal 8.6 improvement is the move of the API-first code to the individual modules, instead of the REST module providing it on their behalf. This might not seem like a significant change, but it is. In the long term, all Drupal modules should ship with web service APIs rather than depending on a central API module to provide their APIs — that forces them to consider the impact on REST API clients when making changes.

Another improvement we've made to the REST API in Drupal 8.6 is support for file uploads. If you want to understand how much thought and care went into REST support for file uploads, check out Wim Leers' blog post: API-first Drupal: file uploads!. It's hard work to make file uploads secure, support large files, optimize for performance, and provide a good developer experience.

JSON API

Adopting the JSON API module into core is important because JSON API is increasingly common in the JavaScript community.

We had originally planned to add JSON API to Drupal 8.3, which didn't happen. When that plan was originally conceived, we were only beginning to discover the extent to which Drupal's Routing, Entity, Field and Typed Data subsystems were insufficiently prepared for an API-first world. It's taken until the end of 2017 to prepare and solidify those foundational subsystems.

The same shortcomings that prevented the REST API to mature also manifested themselves in JSON API, GraphQL and other API-first modules. Properly solving them at the root rather than adding workarounds takes time. However, this approach will make for a stronger API-first ecosystem and increasingly faster progress!

Despite the delay, the JSON API team has been making incredible strides. In just the last six months, they have released 15 versions of their module. They have delivered improvements at a breathtaking pace, including comprehensive test coverage, better compliance with the JSON API specification, and numerous stability improvements.

The Drupal community has been eager for these improvements, and the usage of the JSON API module has grown 50% in the first half of 2018. The fact that module usage has increased while the total number of open issues has gone down is proof that the JSON API module has become stable and mature.

As excited as I am about this growth in adoption, the rapid pace of development, and the maturity of the JSON API module, we have decided not to add JSON API as an experimental module to Drupal 8.6. Instead, we plan to commit it to Drupal core early in the Drupal 8.7 development cycle and ship it as stable in Drupal 8.7.

GraphQL

For more than two years I've advocated that we consider adding GraphQL to Drupal core.

While core committers and core contributors haven't made GraphQL a priority yet, a lot of great progress has been made on the contributed GraphQL module, which has been getting closer to its first stable release. Despite not having a stable release, its adoption has grown an impressive 200% in the first six months of 2018 (though its usage is still measured in the hundreds of sites rather than thousands).

I'm also excited that the GraphQL specification has finally seen a new edition that is no longer encumbered by licensing concerns. This is great news for the Open Source community, and can only benefit GraphQL's adoption.

Admittedly, I don't know yet if the GraphQL module maintainers are on board with my recommendation to add GraphQL to core. We purposely postponed these conversations until we stabilized the REST API and added JSON API support. I'd still love to see the GraphQL module added to a future release of Drupal 8. Regardless of what we decide, GraphQL is an important component to an API-first Drupal, and I'm excited about its progress.

OAuth 2.0

A web services API update would not be complete without touching on the topic of authentication. Last year, I explained how the OAuth 2.0 module would be another logical addition to Drupal core.

Since then, the OAuth 2.0 module was revised to exclude its own OAuth 2.0 implementation, and to adopt The PHP League's OAuth 2.0 Server instead. That implementation is widely used, with over 5 million installs. Instead of having a separate Drupal-specific implementation that we have to maintain, we can leverage a de facto standard implementation maintained by others.

API-first ecosystem

While I've personally been most focused on the REST API and JSON API work, with GraphQL a close second, it's also encouraging to see that many other API-first modules are being developed:

  • OpenAPI, for standards-based API documentation, now at beta 1
  • JSON API Extras, for shaping JSON API to your site's specific needs (aliasing fields, removing fields, etc)
  • JSON-RPC, for help with executing common Drupal site administration actions, for example clearing the cache
  • … and many more
Conclusion

Hopefully, you are as excited for the upcoming release of Drupal 8.6 as I am, and all of the web service improvements that it will bring. I am very thankful for all of the contributions that have been made in our continued efforts to make Drupal API-first, and for the incredible momentum these projects and initiatives have achieved.

Special thanks to Wim Leers (Acquia) and Gabe Sullice (Acquia) for contributions to this blog post and to Mark Winberry (Acquia) and Jeff Beeman (Acquia) for their feedback during the writing process.

Categories: Drupal

How Drupal continues to evolve towards an API-first platform

Dries Buytaert - 19 July 2018 - 4:06am

It's been 12 months since my last progress report on Drupal core's API-first initiative. Over the past year, we've made a lot of important progress, so I wanted to provide another update.

Two and a half years ago, we shipped Drupal 8.0 with a built-in REST API. It marked the start of Drupal's evolution to an API-first platform. Since then, each of the five new releases of Drupal 8 introduced significant web service API improvements.

While I was an early advocate for adding web services to Drupal 8 five years ago, I'm even more certain about it today. Important market trends endorse this strategy, including integration with other technology solutions, the proliferation of new devices and digital channels, the growing adoption of JavaScript frameworks, and more.

In fact, I believe that this functionality is so crucial to the success of Drupal, that for several years now, Acquia has sponsored one or more full-time software developers to contribute to Drupal's web service APIs, in addition to funding different community contributors. Today, two Acquia developers work on Drupal web service APIs full time.

Drupal core's REST API

While Drupal 8.0 shipped with a basic REST API, the community has worked hard to improve its capabilities, robustness and test coverage. Drupal 8.5 shipped 5 months ago and included new REST API features and significant improvements. Drupal 8.6 will ship in September with a new batch of improvements.

One Drupal 8.6 improvement is the move of the API-first code to the individual modules, instead of the REST module providing it on their behalf. This might not seem like a significant change, but it is. In the long term, all Drupal modules should ship with web service APIs rather than depending on a central API module to provide their APIs — that forces them to consider the impact on REST API clients when making changes.

Another improvement we've made to the REST API in Drupal 8.6 is support for file uploads. If you want to understand how much thought and care went into REST support for file uploads, check out Wim Leers' blog post: API-first Drupal: file uploads!. It's hard work to make file uploads secure, support large files, optimize for performance, and provide a good developer experience.

JSON API

Adopting the JSON API module into core is important because JSON API is increasingly common in the JavaScript community.

We had originally planned to add JSON API to Drupal 8.3, which didn't happen. When that plan was originally conceived, we were only beginning to discover the extent to which Drupal's Routing, Entity, Field and Typed Data subsystems were insufficiently prepared for an API-first world. It's taken until the end of 2017 to prepare and solidify those foundational subsystems.

The same shortcomings that prevented the REST API to mature also manifested themselves in JSON API, GraphQL and other API-first modules. Properly solving them at the root rather than adding workarounds takes time. However, this approach will make for a stronger API-first ecosystem and increasingly faster progress!

Despite the delay, the JSON API team has been making incredible strides. In just the last six months, they have released 15 versions of their module. They have delivered improvements at a breathtaking pace, including comprehensive test coverage, better compliance with the JSON API specification, and numerous stability improvements.

The Drupal community has been eager for these improvements, and the usage of the JSON API module has grown 50% in the first half of 2018. The fact that module usage has increased while the total number of open issues has gone down is proof that the JSON API module has become stable and mature.

As excited as I am about this growth in adoption, the rapid pace of development, and the maturity of the JSON API module, we have decided not to add JSON API as an experimental module to Drupal 8.6. Instead, we plan to commit it to Drupal core early in the Drupal 8.7 development cycle and ship it as stable in Drupal 8.7.

GraphQL

For more than two years I've advocated that we consider adding GraphQL to Drupal core.

While core committers and core contributors haven't made GraphQL a priority yet, a lot of great progress has been made on the contributed GraphQL module, which has been getting closer to its first stable release. Despite not having a stable release, its adoption has grown an impressive 200% in the first six months of 2018 (though its usage is still measured in the hundreds of sites rather than thousands).

I'm also excited that the GraphQL specification has finally seen a new edition that is no longer encumbered by licensing concerns. This is great news for the Open Source community, and can only benefit GraphQL's adoption.

Admittedly, I don't know yet if the GraphQL module maintainers are on board with my recommendation to add GraphQL to core. We purposely postponed these conversations until we stabilized the REST API and added JSON API support. I'd still love to see the GraphQL module added to a future release of Drupal 8. Regardless of what we decide, GraphQL is an important component to an API-first Drupal, and I'm excited about its progress.

OAuth 2.0

A web services API update would not be complete without touching on the topic of authentication. Last year, I explained how the OAuth 2.0 module would be another logical addition to Drupal core.

Since then, the OAuth 2.0 module was revised to exclude its own OAuth 2.0 implementation, and to adopt The PHP League's OAuth 2.0 Server instead. That implementation is widely used, with over 5 million installs. Instead of having a separate Drupal-specific implementation that we have to maintain, we can leverage a de facto standard implementation maintained by others.

API-first ecosystem

While I've personally been most focused on the REST API and JSON API work, with GraphQL a close second, it's also encouraging to see that many other API-first modules are being developed:

  • OpenAPI, for standards-based API documentation, now at beta 1
  • JSON API Extras, for shaping JSON API to your site's specific needs (aliasing fields, removing fields, etc)
  • JSON-RPC, for help with executing common Drupal site administration actions, for example clearing the cache
  • … and many more
Conclusion

Hopefully, you are as excited for the upcoming release of Drupal 8.6 as I am, and all of the web service improvements that it will bring. I am very thankful for all of the contributions that have been made in our continued efforts to make Drupal API-first, and for the incredible momentum these projects and initiatives have achieved.

Special thanks to Wim Leers (Acquia) and Gabe Sullice (Acquia) for contributions to this blog post and to Mark Winberry (Acquia) and Jeff Beeman (Acquia) for their feedback during the writing process.

Categories: Drupal

ImageResizer

New Drupal Modules - 19 July 2018 - 3:49am

This module is there to convert Drupal Image style into the ImageResizer format which is a string.

Does I need this module

Categories: Drupal

Pages

Subscribe to As If Productions aggregator - Drupal