How Developing Atlassian Plugins For Cloud Differs From Server
Teamify, the new Confluence plugin from Clearvision, was originally released for Atlassian Cloud. With the new release of the Server version, one of the developers behind Teamify takes a look at the differences he experienced in developing for Cloud vs Server.
As part of Clearvision’s Accelerator squad, I’ve been working on numerous new products in the last year or so. Most recently, we released our Teamify plugin for Confluence, which is now available in the Atlassian Marketplace, first for Cloud and then Server.
For now though, I’d like to focus on my own behind-the-scenes experience of working on this project, and what it taught me about developing Atlassian plugins for Cloud versus Server. The Atlassian suite of tools offers significant resources for plugin development, giving developers the opportunity to vastly extend tools beyond their original capabilities.
However, with the recent advances in Atlassian’s cloud-based offerings, how does developing for Server compare to developing for Cloud?
Atlassian-connect.json Add-on Descriptor vs Atlassian-plugin.xml
At the heart of any Atlassian plugin is a central file that controls the available components used in that plugin. These files act as mediators between the Atlassian interfaces and the vendor-written components. Both of these files define plugin keys, name descriptions and vendors. Components such as web sections (which define placement of sections on pages) are available in both the cloud-based plugins and the server-based plugins.
Web section in atlassian-plugin.xml
Web section in atlassian-connect.json
Unlike the Atlassian-plugin.xml, the Atlassian-connect.json only describes the key resources and their locations. This leaves the application of any logic to the server, which serves up web pages. The Atlassian-plugin.xml, on the other hand, prescribes dependencies, some business logic components and even active objects used for storing data. The result is that the cloud-based Atlassian-connect.json is more lightweight, though slightly less prescriptive.
Unsurprisingly, the cloud-based APIs provided are far more extensive. One of the main reasons for this is the inaccessibility of key variables from JIRA. In the server-based plugins, this data is directly accessible via the JIRA database and from the Atlassian Java API. However, for cloud applications, all this information must be exposed and accessible via the library of REST APIs that Atlassian provides.
As a result, the development of REST APIs for cloud is accelerated, with many prototype “experimental” APIs being promoted to full REST APIs.
Confluence Server API for original Confluence page:
Confluence cloud-based API for original Confluence page:
The stagnation of the server-based REST API development means that when porting cloud-based plugins to server-based plugins, alternate methods must be looked at to access data from JIRA or Confluence. In many cases, this is still possible due to the underlying access to resources on the server, but this requires two implementations of the same functionality.
When porting JIRA or Confluence server-based plugins into a cloud-based environment, however, there are still limitations of what is achievable, due to the lack of access to the underlying architecture of JIRA. This is becoming less of a problem with the rapid development of the REST APIs as Atlassian promotes its cloud-based resources. However, it is entirely possible to have functionality available in server that is not possible to move over to Cloud later.
Develop for Cloud first! This is the most efficient way to make sure both versions have full functionality.