Before Forge, Atlassian Connect was the only way to write add-ons for Jira Cloud. Connect has been around for many years and at one point was even earmarked to replace the OSGI plugin model for Jira Server and DC. This, however, did not happen in the end, mostly as a result of the opposition from add-on developers. Atlassian do listen to the community.
However, with the introduction of Forge, there are two big questions:
Will Forge ultimately replace Connect or if they will continue to live alongside each other for many years to come?
Which platform should you use for your next add-on?
Before I give you my opinion on those two questions, let's just compare Forge and Connect to each other and see where their strengths and weaknesses lie.
Atlassian Connect
Connect is the classic way to write your Jira Cloud add-ons. The beauty of Connect is its loosely-coupled architecture. In essence this means that Jira and the add-on live in completely different places, and they are only connected through a very thin protocol. Connect add-ons are in fact web applications in themselves, which serve the add-on content to a Jira instance.
The only defined touch points that an add-on developer has to adhere to are three things:
The atlassian-connect.json descriptor, which defines what services the add-on provides to a Jira instance
The structure of the requests that Jira sends to the add-on as a result of the content of the atlassian-connect.json descriptor
And how an add-on interacts with Jira via the REST API
Other than that, it is entirely the add-on developer's choice how they implement their add-on. You can write it in any programming language you like, and you can run it on a laptop at your home, a professional data centre or a cloud-hosted environment like Amazon Web Services, Google Cloud Platform or Microsoft Azure.
It can run anywhere. The only condition is that Jira and the add-on need to be able to communicate with each other.
So this then brings us to Connect's ultimate strength: it is hugely flexible and allows add-on developers full control over the architecture of their solution, how they interact with Jira, what data they store, where they store data, and in which format data is stored.
That strength also comes with a few downsides:
Trust: Connect add-ons have full access to a customer's Jira instance and can store a customer's data locally. This means that customers do not only entrust Atlassian with their data, every add-on developer also needs to be considered a trusted supplier, and for many enterprise-grade customers this means that they need to go through supplier due-diligence with all add-on vendors.
Security: Both Jira and Connect add-ons are separate solutions, and they need to be kept secure separately. We all accept that it is Atlassian's responsibility to keep Jira secure. However, we must not forget that if a hacker broke into an add-on vendors systems, they could potentially gain access to the Jira environments on which the Connect add-on is installed. Again, this means that many enterprise-grade customers need to go through a security due-diligence process with add-on vendors.
Availability: Atlassian make sure that Jira is up and that they meet their Service Level Agreements (SLAs). However, for many Jira users who rely on add-on functionality, if a crucial add-on is unavailable due to a problem at the add-on vendor's end, then their Jira is essentially not usable.
And what this also ultimately means is that Connect never caught on as a quick-scripting or micro add-on solution. If you are a Jira admin wanting to automate something in your workflow or writing a custom validator, the overhead of having to host your add-on somewhere and having to look after it for years to come meant that Connect was pretty much a non-starter for that use case.
Atlassian Forge
And this is where Forge comes in. The idea of Forge was to learn from Connect and provide a solution that makes it a) easier to write add-ons and b) removes the requirement for the add-on vendor to host the add-on.
Atlassian wanted to increase trust in add-ons and lower the entry threshold for add-on vendors. In fact, what connect has done is that it has empowered virtually anyone to write their own solutions for their Jira instances. You no longer need to be an add-on vendor or operate like an add-on vendor to write, use and potentially even share add-ons with others.
The way Forge works is that Atlassian have created a turnkey solution for add-on development. You are required to use the "forge" command line tools to create and manage your add-ons and write the add-on in NodeJS. Atlassian have control over what add-ons can do (even behind the scenes) and what communication is allowed.
Forge add-ons run in Atlassian's environments, meaning that once you have developed an add-on and deployed it, you no longer need to worry about how to run it, how to keep it secure and how to look after it. Atlassian take care of all of that.
This addresses many of the challenges we saw with Connect:
Trust: Forge add-ons are are run by the same vendor who looks after your Jira instance: Atlassian.
Security: Atlassian have created and look after the security model for Forge apps. It is no longer the add-on vendor who looks after the spare key to your house (your Jira instance).
Availability: Atlassian run the add-ons. True, there could still be challenges with Forge apps not being available when Jira is. However, it is the same vendor looking after both environment, which creates consistency and provides the customer with a single wringable neck, as they say.
And last but not least, this has empowered those who would previously never have consider writing their own solutions to give it a go. Jira admins will be able to write their own scripted solutions, and the learning curve is not very steep.
Having said all of that, there is of course a big downside, especially for those wanting to write full-featured add-ons. When you put add-on vendors in a tightly controlled framework with strict restrictions, then many of the add-ons we have on the Atlassian Marketplace today would never have emerged. You need flexibility for limitless innovation, and Forge is very restrictive by design.
Conclusions
So what does this all mean? How about the answers to those questions above?
Will Forge Replace Connect?
You can probably guess my opinion on this by now. Forge is great, and I strongly believe that Forge is the future. However, I do not believe that Forge is the future for everything. I predict that Connect will be around for many years to come.
Which Platform to Use? Forge or Connect?
Well, the very simple answer is: if you can use Forge for what you are trying to achieve, then you should. Why make life difficult for yourself when Forge can take care of so many things for you?
However, the answer to this question may also depend on who you are and why you are writing an add-on. I suspect that many commercial add-on vendors will continue to use Connect even for add-ons that strictly-speaking could be written with Forge. They already have the procedures, infrastructure and processes to maintain the Connect environment.
For Jira admins or Atlassian consultants working with clients, Forge is a great solution to extend Jira without all the hassle that comes with looking after a Connect app.
Next Steps
Why not start by learning about Atlassian Forge today by taking my full course on Udemy: Jira Cloud App Development with Atlassian Forge
And if you want to learn more about Connect, then there is a course for that too: Jira Cloud App Development with Atlassian Forge
Comments