APIs are going to transform the world: they not only benefit from network effects caused by specialisation, the data they collect also makes them a prime candidate for the emergence of specialised Artificial Intelligence. Considering how powerful APIs are, it would be an injustice should they remain the privilege of developers.

Not enough developers

According to an Evans Data Corporation’s study (2014) on the global developer population, there are today, worldwide approximately 19 million developers. By the year 2020 this number is expected to climb to 25 million, in a total population of nearly 8 billion people, that means that only 0.31% of the world will be developers. If you take into account that developers also need to build our APIs and all the other software we use, it is clear that there are simply not enough developers that can act as the gateway to API consumption.

Why we need a GUI for the API web

Not too long ago computing used to be an obscure activity that only developers could participate in. GUIs changed this, they turned computing into a mainstream technology. The API web today, is where general computing was a few decades ago. Its promise is clear but it hasn’t yet become a mainstream technology. That is why I believe we again need a GUI to emerge, a mashup tool that makes the API web accessible through a point and click interface.

GUIs make it easier for new users to use software because:

  • GUIs are self explanatory: it’s possible to configure an application with a GUI, just by filling in the forms of its admin interface.
  • GUIs offer constraints that get you through analysis paralysis faster, so that you can focus your creativity on the application model rather than on the implementation.
  • GUIs make it easier to discover the full feature space of an application, just by clicking through the navigation model.

GUI as a service

Several companies have identified this opportunity (e.g. Zapier, IFTTT, IBM's Bluemix, Appgyver,… ) and are working on GUIs that integrate a multitude of services. So far these applications are conceived as centralised cloud services. The advantage of such a setup is that its development and maintenance are executed by a dedicated product team and financed by a large group of users.

The disadvantage is that you come to depend on a single point of failure: even if you use abstraction to make it possible to switch APIs, all the applications you build are bound to a single platform. If, for whatever reason you want to switch providers this could lead to considerable reimplementation costs.

Drupal, an Open source middleware

I have been talking with a number of people in the Drupal community about how unique Drupal is as a site builder tool. Drupal is kind of special as a CMS because you can use it to build really complex behaviour without a single line of code. The rules module for example exposes a Turing complete trigger response system through the UI. With it you can do amazing things that in other CMSs can only be done with custom code.

What is also really exciting is that Drupal already has a lot of integrations with APIs: there are over 3000 modules on Drupal.org that are tagged as third party integrations. A lot of popular APIs already have modules. Some API integrations are installed on thousands of sites. A lot of API companies are currently not really aware of this and overlook the opportunity to market to a really large group of people that could get acquainted with their services.

The case for an open source GUI for the API web

Be it Drupal, or another open project, I believe that there is a case to be made for an open source middleware that can connect and process the services from different APIs. Since standards are arising around API design it might even be possible to create a standard interface that allows you to consume APIs that conform to the Open API Initiative standard (formerly Swagger) or to API Blueprint or one of the other formats.

For API consumers, an open source middleware would guarantee independence and prevent single points of failure. An abstraction layer, that lets you switch out APIs combined with an open source middleware in which you build your applications would prevent lock-in and give companies maximum resilience. I think Drupal is a great candidate for this.

25'000$ prize for a Drupal module

A few months ago, a Drupal module we created won the first runner up prize for the Context.IO Devpost challenge. The module leverages Drupal’s Feeds module and makes it easy for site builders to query email accounts and to map the information into a Drupal data model. It is a great example how you can build complex web applications all from the user interface.

Drupal 8, a crossroad

If we want Drupal to become the GUI for the API web, we need to make sure that we keep supporting site builders. Drupal 8, touted as the site builder’s release, has a lot of improvements that greatly benefit site builders: Configuration management, a mobile editing interface and numerous improvements to the UI make it the best release for site builders so far.

At the same time because of its Symfony foundation, it has become a lot easier in Drupal 8 to extend functionality with some Symfony code. This risks diverting some of the resources that consulting companies typically would invest in reusable Drupal modules towards single use custom code that leverages some of Symfony’s community packages, bypassing the need for a GUI.

Clickers unite

For these reasons I think it’s time for site builders to claim their place in the community as Drupal’s core audience. Today sitebuilders are an audience that is sometimes looked down upon.

Too often site builders experience the following:

person 1: So what do you do?

person 2: I’m a site builder, I use the interface to configure Drupal sites.

person 1: Oh (slightly disappointed), so you are not a developer...

Drupal was built for site builders, it is time for us to unite and claim our voice in the community. If you are a sitebuilder make sure to sign up for Drupal Uncoded.

This article was based on a presentation I did at APIdays Paris December 2015. The recording of my talk can be found at https://www.youtube.com/watch?v=liMbivP3rB4&ab_channel=KristofVanTomme

About the author

Kristof van Tomme

CEO, Co-founder

Kristof Van Tomme is an open source strategist and architect. He is the CEO and co-founder of Pronovix. He’s got a degree in bioengineering and is a regular speaker at conferences in the API, DevRel, and technical writing communities. For a few years now he’s been building bridges between the documentation and Drupal community. He is co-organiser of the London Write the Docs meetup, and cheerleader for the Amsterdam and Brussels Write the Docs meetup groups. This year he is working on a number of new initiatives to help API product owners learn from their peers (API the Docs and the API product owner masterminds).