We’re in the process of migrating our onprem Jira and Confluence instances to cloud. We’ve done quite a lot of customization on our instance using Adaptavist Scriptrunner (for ex custom scripted fields, Confluence gadgets, etc).
We’ve started to rewrite all of the gadgets and functions we need, into Forge apps and so far, so good, except for our scripted reporting that we utilize.
Currently, with the Forge invocation limits in place, we won’t be able to use just Forge (on its own) to create these reporting gadgets. We’re exploring possibility of creating the components, that do the heavy lifting, in our AWS VPC and then have Forge connect and retrieve the data. We’re all still new to AWS and we’ve started our journey on the tech,
Can an Atlassian Forge app connect to an AWS VPC? (apologies up front if this is a dumb question)
Technically, yes. But not in the way that would be useful to reporting.
To elaborate the “technical yes”, a recent announcement opens up a way to call “external compute” using OAuth 2:
That’s not using AWS VPC for security but it would be possible to put OAuth 2 in front of a VPC using AWS API Gateway.
To elaborate why it’s not useful for reporting, whatever is inside your VPC that would do “the heavy-lifting” needs to query Jira. (That’s the heavy-lifting for reporting, right?) In order to query Jira, those external components need some kind of authentication, which Forge cannot share. So those external compute components would need to operate as their own OAuth 2 App, separate from Forge.
One could still have Forge talking to that OAuth 2 back-end; however, the architect in me doesn’t like splitting components this way. The dual-auth would be too easy to run into permissions mismatches that leak data. And the code bases would be tightly coupled, while needing pretty different deployment pipelines. Hence, I would recommend Connect (even if older and less shiny) instead of Forge.
I’ll discuss with our architect as well but this does give me some hope. We’re starting our POC process of exploring which AWS components to use for which scenarios/ gadget requirements and having Forge be able to talk to them forms a big part of it.
It would be great to hear how you eventually plan or implement the Forge interaction with your own compute resources. Between use cases and technical architecture, this is an area where many in the community are eager to learn from pioneers like yourself. I do hope you’ll post as you learn more.
@DeonPetrusMeyer - That’s an interesting use case and discussion, which we are contemplating for a while in context of a future Cloud version of our Automate with AWS (Jira) app (on hold until the Automation for Jira/Confluence Forge modules are available).
I generally share @ibuchanan’s assessment, but would like to throw Forge Web trigger events into the discussion (see e.g. the Issue alerting app sample), insofar those allow you to expose a private API as a relay to the host product (which can only run authenticated via asApp() right now).
Of course, viability and constraints depend on the details of your use case, so the “heavy-lifting” needs might still hit Forge function limits, and you also need to handle external authentication yourself and thus potentially run into “dual-auth [and] permissions mismatches that leak data” (the trigger URL seems reasonably obfuscated for spikes and low-risk scenarios though).