Data exchange between Forge apps

Forge
1

Hi,
I’m developing a Forge app built of Jira and Confluence modules. And I want to share user entered data between those (e.g. some user input made in a Confluence macro should be available in a Jira issue panel). I would like to ask which options exist and what are their pros/cons.

I already have some ideas I would like to share. Would do you think about those? Do you already have experience with one of them? Did I miss any good alternative?

From my understanding every Forge storage option can’t be used, because storage is separated by installation. I could bundle my app in one deployment, but it will always result in 2x installations (Jira and Confluence). :x: Hence, this is not an option.

I could use a web trigger (or multiple) and build some kind of API behind it. For example, the Confluence app could host the “server side” (i.e. also the storage) and the Jira app would be the “client”, using the “web trigger” to fetch data.
:x: feels like misusing the feature
:x: configuration overhead for customer. The “client side” app somehow needs the web trigger URL of the “server side” app (+ customizable auth token)
:white_check_mark: no external third-party involved
:white_check_mark: can build a use case tailored API

I could use any external, cloud hosted, data storage solution.
:x: data does not reside on Atlassian servers (could be a problem for some customers)
:x: additional costs
:white_check_mark: obvious solution (feels right) to share data between two isolated silos

I could leverage Atlassian REST APIs. For example I could store all data in Confluence page properties and put a label on relevant pages. On Jira side it is then very easy to request the labeled pages and their properties.
:x: page properties could be edited (and broken) by anyone
:x: great for metadata and simple attributes but not for larger amount of user given data
:white_check_mark: easy to use and everything built-in

Looking forward for your feedback!

2

Hi @AndreasZink,
You might want to look at RFC-84 Cross-product apps

3 Likes
3

Although I did not get feedback regarding the different options, I’d like to share my decision.

I’m using a webtrigger and have built a RPC API (remote procedure call) on it.

  • The Confluence app hosts a settings page, providing the connection details for the API. This is a URL and a custom API auth token.
  • The Jira app also hosts a settings page, providing a form to save the connection setup.
  • The webtrigger validates the auth token on each request. This is not mandatory, but be aware that this is a public endpoint.
  • The webtrigger handles HTTP POST requests and the body format is aligned to JSON-RPC specification, e.g. {“jsonrpc”: “2.0”, “method”: “getData”, “params”: { “filter”: “foobar” }, “id”: 1}
  • Based on the given RPC method and params, the handler calls a corresponding backend function.

:white_check_mark: this really works well. I also think that an RPC style API is a good match in this case.

Last but not least, I signed up for the RFC-84 EAP. I hopefully can compore those solutions, but from what I have read about RFC-84, it should be a good match for my usecase.