Accessing Forge Storage externally and the future of Forge Storage


I’d like to know if there’s any way to access the Forge Storage from outside, for example from an AWS Lambda.
I’ve tried the Web Trigger functionality, but the url where the trigger can be called is generated, and can only be generated from within Forge.
We need to know where to access the Storage when a scheduled job starts outside of Forge, therefore we’d have to store this url somewhere else. Using another storage to store the location of the actual storage kinda defeats the purpose of using this system at all… Not to speak about the severe quota limitations.

My question is:

  • Is there any other way to access the Storage API externally?
  • What are the plans with Forge Storage going forward, can we expect better functionality than a plain key-value store? The current implementation seems more like a proof-of-concept or a tech-demo, than a solution for real-world scenarios.

We ask ourselves the same question. Currently the Storage API doesn’t cover basic query functionalities. When we asked Johnny Ferguson (Head of Product Management, Ecosystem Platform) about it in the last Forge webinar he said: “RDBS [Relational Database System] is something we think we will probably have to support in a remote fashion for quite a while.”

That is why we now start implementing Forge apps with a remote backend on Firestore. Not ideal. But staying on Connect feels bad too. Maybe we can migrate our persistence layer back to Atlassian Cloud when Storage API or sth. else covers the requirements of data queries.


Here is @Johnny answering @JulianWolf’s question: Forge Roadmap Webinar: Q4 2021 - YouTube

Your workaround is exactly where I would have headed.

The Forge team knows that there are a lot of opportunities to add to the Storage API and have it on their roadmap as a future item: Trello


Echoing @MateKavaleczMidori 's question — having a way to store app properties (equivalent to the connect API) that are accessible externally would be super useful!

The only workarounds currently seem to be storing a web trigger URL somewhere externally, or to add properties to another entity (projects, issues, users — an approach I imagine could cause complexity if a new user or project is created, etc). I can’t see any mention of this in the roadmap, is this something that’s being considered?

The only properties I see on the Forge public roadmap for developers is @JakubMierzewski’s
jiraProperties Forge Module but, it doesn’t have any details on the card… :frowning:

Also quite a few FRGE issues with properties in them: Forge - Issues - Ecosystem Jira

Let me go bug @JakubMierzewski and see if there is something similar in the works.


[Forge Jira entityProperty module EAP - #2](https://jiraProperties Forge Module) is released, I just have updated a public roadmap. @JimmyLoughran is it solve your use case?

1 Like

Hey there — it is awesome to see indexable entity properties.

In my particular use case I’d like to store (and read) properties against the “app” entity, which is possible in Connect.

The current solution in Forge appears to be the storage API, that can be exposed / accessed via a web trigger.

Are there any plans to include app entity properties in Forge, that are accessible directly via an API?

In my particular use case I’d like to store (and read) properties against the “app” entity, which is possible in Connect.

Hi @JimmyLoughran , sorry for the delay on this. If I understand correctly, you’d like to persist data from your Forge app, and then make that data readable via an API by a separate process – is that right? If so, you’re right that the best approach for now is to use a web trigger.

Could you help us understand what the downsides of this approach are for your use case, and what would you expect from a better solution?

Also, out of curiosity, when you use App Properties for this in Connect, do you run into any issue with auth? (I ask because IIRC app properties were originally intended to be used within the context of an app rather than shared outside the app, so I’m note sure they’d be optimised for your use case).

We have a similar use case where we would like to store app-level configuration (per tenant) and then read it from a third-party service that authenticates via OAuth2 3LO.

The Connect app property does not work because:

  1. it is not accessible via standard Jira API (via OAuth2 3LO)
  2. it is not accessible from Forge (considering we will at some point migrate the Connect app to Forge)

One way we were thinking of simulating an app property is by storing an entity property against the Connect app user. This entity property should be readable via standard Jira API, provided the caller knows the Connect app user id.

This approach works for Forge apps as well as for third-party services, provided the Connect app user id does not change (also not when migrating a Connect app to Forge).

The blocker for us is that there is currently no clear commitment that the app user id is guaranteed to always remain the same. In discussions with Atlassian, we had some indications that this is being considered for Connect to Forge migrations but may not be fixed in the near term.