Since some time before last year, at Metadrop we have started to experiment with what is called Headless Drupal and developing JavaScript applications on the client side. The idea of Headless Drupal, also called decoupled, is simple: Drupal is an excellent content manager, but certain developments require a complex front-end beyond the possibilities offered by Drupal's theming system, or at least with reasonable effort. The need for greater interactivity or the ability to publish content on multiple channels (the classic example is a website and a mobile app) are requirements that make it more convenient to separate into two layers: one layer that manages the content, and a second layer on the client side that consumes the content offered by the first layer.
Drupal 6 already had the Services module that allows exposing Drupal content as consumable services for external applications. Drupal 7 saw the addition of other modules with the same purpose, such as RESTful Web Services and RESTful, both aimed at REST, but it was in Drupal 8 that this strategy was enhanced, turning Drupal into an excellent choice when building content APIs.
Mobile applications
Our first approaches consisted of developing APIs on the content of a Drupal site that were consumed by native applications for both Android and iOS. This allowed us to start gaining experience with this type of strategy and stop seeing mobile applications as simple users and start thinking about them from a developer's point of view. Metadrop was born with the idea of specializing in Drupal, leaving aside other technologies to be true experts in the system (thinking about the idea that jack of all trades, master of none), so learning almost from scratch how to develop a complete mobile application on both Android and iOS seemed like a bad idea. Therefore, we relied on close collaborators who already had that experience to start developing the first applications that used Drupal as their content manager. From there came applications like the Honky Tonk Bar in Madrid:
These experiences encouraged us to continue working in this direction. But in parallel, we had also started playing with client-side JavaScript-based applications.
Client-side JS applications
Technologies and trends evolve, and for some time now, websites often require visual components with interactivity and capabilities that cannot reasonably be achieved without using one or more JavaScript frameworks. Faithful to our philosophy of focusing on Drupal, we decided not to venture into the crowded jungle of the JavaScript framework, library, and snippet ecosystem and instead choose a well-established all-round technology: Angular JS. We were aware that, for each application, there was likely a combination of JavaScript libraries and techniques that would be more optimal than Angular JS, but to find that combination, we would need to stay up to date with hundreds, if not thousands, of available JavaScript libraries, knowing their strengths and weaknesses to find the right recipe for each case. Angular JS, however, is a very complete framework, not a simple library, a JavaScript development stack that covers all the needs we might have in a very convenient way. It is well documented, has a lot of available contributed code, and the solidity of having Google's support behind it.
With Angular, we could leverage all our web development knowledge, since it is essentially applications heavily based on the core web technologies: HTML, CSS, and JavaScript.
The choice was a good one, in our opinion, and thanks to it we were able to develop two projects for the recent 2016 Rio de Janeiro Olympic Games. The first, simple but functional, were live scoreboards for table tennis competitions. In that project, we also had to deal with receiving data through the live Olympic data protocol ODF (Olympic Data Feed), but that is another story that might also be worth telling.
But the real test of whether the decision was right came with the competition results application for the International Archery Federation website. It required consuming around twenty different services, displaying data for both live and past competitions, and allowing users to watch live matches or replay them once finished (do you want to see how the semifinal match in which Ku Bonchan, the winner of his category, defeated Brady Ellison, one of the big favorites, went down? Just follow the link and play with the match visualization component). It also allows viewing podiums, elimination tree views, participant and team data, and the ability to link directly to each component to share matches or other data. And all of this was served from Drupal backed by data services provided by the World Archery organization.
Finally, the application debuted for the Rio Games, demonstrating that Angular was a very powerful tool that met our needs.
You can check all the Rio results at this link.
Web-based mobile applications
After having done the backend for several mobile applications and developing a complex JavaScript application, we needed to take the next leap: creating our own complete mobile applications. We already had enough experience for that; we just needed to put the pieces together: Drupal for the backend, Angular for the application, and a new player, Ionic, to generate the web application itself.
Ionic allows developing mobile applications using web technologies, that is, the old familiar HTML, CSS, and JavaScript. The result, relying on Apache Cordova, are natively installable applications with a look and behavior very similar to native applications.
Since not everything was going to be that easy, and since we like to experiment with new technologies, we did it with the new version of Ionic, version 2.x, which is based on Angular 2. If you are up to date with Angular development, you will know that from version 1.x to Angular 2, the changes are enormous. Much more component-oriented (a great decision), Angular 2 can be, and it is actually common to, write using TypeScript, a free software language that is a superset of JavaScript that transpiles to executable JavaScript code for browsers. However, I must say that although it is a bit difficult at first, the adaptation to both TypeScript and Angular 2 is not complex and leaves a very satisfying feeling. During development, Angular jumped to version 4, the current version, but without major changes, so we barely noticed differences.
We recently completed and launched into production the first fully Ionic-based app for both Android and iOS: the official mobile application of World Archery. Although apparently simple, it has a complex engine behind it that will be the basis for future updates already planned.
The biggest challenges were, on one hand, adopting Angular's reactive philosophy, based on RxJs, and on the other hand, reflecting all the client's requirements (offline functionality thanks to local cache fallback in case of an inaccessible server, automatic refresh of interrelated data, complex business logic in terms of service consumption). Separating the engine into an external library will even allow us to include application functionalities (mainly views) on the WorldArchery website using the same code base.
If you want to try it, just install it, it's free! And we promise that the app does not do anything strange with your data or any other dubious ethical practices so typical nowadays.
Conclusions
The combination of Ionic with Angular allows us to build both web interfaces with a high degree of complexity and interactivity and to develop mobile applications for Android and iOS using a single codebase. With Drupal as the backend engine, we feel capable of taking the leap into mobile development with a solid foundation behind us. Although the learning is not a short-term matter, the investment in research and development is widely satisfied given the results obtained: we now feel able to offer not only a web application with the best content manager as its engine, but we are also capable of building applications on the other side of headless Drupal, something we believe will be increasingly in demand in the future.
