blog image

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.

Check out Teamify for Confluence on the Atlassian Marketplace

If you’re interested in learning how Teamify combines the colour-based personality profiles of Clarity4D with the collaborative power of Confluence, head to teamify.io.

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.

Teamify

Confluence profile displaying a Teamify personality profile and communication tips

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

<!-- A new section named "Samples" in the Admin menu -->

<web-section key="samples-section"

           name="Samples"

           location="system.admin"

           weight="110">

  <label>Samples</label>

</web-section>

Web section in atlassian-connect.json

"webSections": [

           {

               "location": "system.admin",

               "weight": 110,

               "name": {

                   "value": "Samples"

               },

               "key": "samples-section"

           }

       ]

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.

REST APIs

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:

“/rest/experimental/content/917506/version/1”

Confluence cloud-based API for original Confluence page:

“/rest/api/content/917506/version/1”

Conclusions

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.

TL;DR

Develop for Cloud first! This is the most efficient way to make sure both versions have full functionality.


Interested in trying out Teamify? You can get it for free in the Atlassian Marketplace, or chat to Clearvision at the upcoming Atlassian Summit to find out more!

Full stack developer as comfortable with SQL in a back-end database, as with a javascript library running client-side.