Forge Feedback after converting existing connect app

Easy Agile spent a week converting an existing Connect app to Forge and we would like to share some feedback. This is our second big experiment with forge, the first being this Forge app for Codegeist in 2021, feedback for that here

We felt a bit more comfortable with forge this time around but still ran into a few challenges / blockers. We would appreciate any advice you have on proceeding from here

Improvements since our last exploration of Forge

/graphql endpoints faster

When we created a forge app for 2021 the graphql endpoints appeared slow, and whilst they were still slow with forge tunnel, they appear to be faster in production mode than they were last year.

Easier to manage app height

We liked that it was easy to manage how much of the space in Jira the forge iframe took up.

Simple install process
Installing other developer’s forge applications was a relatively simple process.


Unable to tunnel when running inside a Docker development container

We develop our applications from within a docker dev container, but we were unable to use forge tunnel while inside the container. This has created an inconsistent developer experience as we had to move the application outside of our usual working environment and modify the structure of the app to get it to work outside this environment.

Forge tunnel requests were slow

Requests sent through the tunnel took upwards of 10 seconds to complete. This made the app really difficult to use and test during development.

That being said, when run on our staging environment with a production build, the requests were much faster.

Forge tunnel builds were slow

When making changes to the Forge code, we noticed builds were taking ~60 seconds to rebuild, which feels slow compared to our Connect API rebuilding in ~5-10 at most.

User Permissions

Each user of the application has to manually accept the app’s permissions in order to use it. This happens again whenever new permission scopes are added to the app. Overall this is a clunky user experience.

We believe app permissions should be managed by the JIRA Admin, as it will be a pain point if every user needs to accept a long list of permissions for every app they install.

Database Storage

Our TypeORM modules use relational database structures. In order to use Forge’s Storage API, we needed to convert these data structures to “key-value” structures. This comes with concerns around speed and timing, as well as difficulties in generating queries on the data.

In the future, is Forge likely to have an alternate storage solution?

Current Board

We use the current boardId in our application in order to render a story map of issues in that board. In order to get this working, we had to create a workaround board selector based on the projectId . The user would then have to select which board they would like to use. We think this is a poor user experience and we recommend that the boardId be passed down in Forge’s Custom UI view context.


We have a lot of existing data in the Connect app and could not see an easy migration path to move that data into the Forge Storage API.

Is there a process or planned method of doing this?


1 Like