What is Atlassian Forge? Connect on Forge, Forge Remote, and Native Forge

[#1]

A few days ago, I was talking with our product team about the architecture behind our Atlassian Marketplace apps at Deiser Apps (part of Devoteam. At some point, someone mentioned that all our Cloud apps are now either natively on Forge (Budgety & Capacity) or fully on Forge Remote (Projectrak & Exporter).

For the technical people in the meeting, that makes sense (and not even for all of them!). On the other hand, for the business-oriented people, that rang a bell, but some of them weren’t that sure about it. Questions like "What does that even mean?" "Weren’t we Forge already?"

If people working every day around Atlassian Marketplace apps can still have these questions, I imagine plenty more people have them too. So, instead of assuming everyone speaks fluently in “Atlassian dev,” I thought it could be useful to lay out these basic concepts.💡

So far we have mentioned Forge, but nothing about Connect. This is important! Both extend Atlassian Cloud platform functionalities. The important part is where the platform is heading. So, first things first:

What is Atlassian Connect?

Atlassian Connect was the framework traditionally used to build Atlassian Marketplace apps for Atlassian apps (Jira, Jira Service Management, Confluence, etc.). The flexibility of this framework was useful for the Atlassian ecosystem for many years. Until Atlassian announced the end of Data Center.

Atlassian now treats Connect as legacy (“outdated technology”), and new Connect-based apps cannot be published on the Atlassian Marketplace. The new way to do it is based on the Forge platform. Not meaning that every app built based on the Connect framework has stopped working.

What is Atlassian Forge?

Atlassian Forge is the development platform to build Cloud apps for Atlassian apps. And here’s where the differentiation I want to make with this post.

There’s a relevant detail that can easily get lost when we say “an app is on Forge,” as not every Forge app has the same architecture.

The three Forge implementation patterns:

To successfully survive most Atlassian ecosystem conversations around such a technical topic, there are three useful ways of understanding the current landscape:

1. Connect on Forge: This is probably the most confusing one, given it mixes the previous and outdated framework (Connect) with the current platform Atlassian is pushing (Forge). This basically means that a Forge app still uses some modules belonging to Connect (it’s part of a transition process).
   
   There are Atlassian Marketplace Partners (the companies selling apps in the Marketplace) who have been building apps for years in Connect, and now they have to bring everything to another new platform… that implies a lot of work, complexity, and risks. That’s why Atlassian has introduced this incremental adoption path, where the first step (let’s say that) is Connect on Forge.
   
   This means that the app built in Connect on Forge has entered the Forge universe, but some parts of its previous Connect architecture are still traveling with it.
   
   
2. Forge Remote: This one deserves special attention because the word “Remote” can, somehow, make people assume the app is not actually on Forge. Because it actually is! (as it’s the case with Projectrak for Jira and Exporter for Jira).
   
   The Forge Remote implementation allows Forge apps to integrate with services hosted on infrastructure controlled by the app developer, which means that the app uses Forge modules and capabilities while securely communicating with an external backend.
   
   
3. Native Forge: This implementation type is the final boss. Native Forge describes apps built around Forge’s native capabilities without Connect modules, also known as Full Forge. This implementation uses Forge infrastructure while also using Atlassian-provided storage services to save and manage app data.

This is important to note because you’ve probably seen posts from Marketplace Partners announcing they’re on Forge this way or that way, and hopefully this can provide more context to those announcements.

As the Atlassian Marketplace has been around for quite some time now, many apps available there are carrying years of engineering decisions behind them, and this change might mean totally rebuilding an app with Forge capabilities.

So, next time you see that an Atlassian Marketplace app has moved to Forge in any way, you have enough context to value that change.

[Aron Gombas _Midori_]

@Huwen Arnone _Deiser_Devoteam_ 

I’d like to clarify a few points:

• Atlassian Connect vs. Data Center: Connect has no relation to Data Center! Connect was built specifically for Atlassian Cloud.

• Data Center & the P2 Framework: On-premise Data Center apps rely on the legacy Plugin2 (P2) framework. While Atlassian has announced the Data Center EOL, P2 remains active and necessary to maintain existing Data Center apps.

• Connect Deprecation: It is correct that Atlassian is deprecating Connect.

• The Modern Cloud Standard: Forge is Atlassian’s modern, Cloud-only framework designed to replace Connect.