Forge Feedback after converting existing connect app

Forge
,
1

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.

Challenges

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.

Migration

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?

Thanks

5 Likes
2

Hey Nicholas,

Sorry for the delay in getting back to you. This is great feedback and touches on a range of common challenges being felt by developers. There’s not a lot of quick wins there, but there’s a lot of work going on that should address many of those problems over the coming quarters.

Challenges with the Forge tunnel
To paint a bit of context, the Forge CLI uses a Docker container in an effort to reduce the complexity for developers who would otherwise need to install a list of dependencies to support the underlying Forge runtime. At the time, this solved one of the largest points of friction in Forge developer onboarding.

As you’ve pointed out, using a docker image comes with trade-offs. It’s also a rather large contributor to the performance aspects that you point out. This is mostly due to the filesystem I/O and limited resource allocated to the container.

There is good news, though! As Forge has evolved, so have the needs of our developers. We’re currently in the middle of a multi-quarter initiative to build our next generation Javascript runtime environment. Our aim is to provide a more robust compute offering that helps with aspects of performance, developer experience, and general usability. This work should enable us to re-evaluate our usage of docker and potentially remove it / provide options for developers to go without.

User Permissions
We agree this is a clunky experience, and we’re actively addressing this. See We're removing the allow access prompt for Forge apps and follow the roadmap card on Trello.

It’s been a while between when we announced this work and now, it’s a bit of a knarly engineering problem for us to solve. We have a team working on a solution as we speak and we hope to be in a position to share more soon.

Database Storage
The short answer is yes - we have plans for supporting alternate storage options in Forge platform in future (including relational database support), however we are still exploring what this will look like and when it may be available. As we progress with these explorations, we will seek guidance and feedback from developer community to better understand the key requirements for the alternate storage solutions (including relational DB).

In the shorter-term, we are working on improving our key-value storage, including support for query-by-value, additional querying filters and support for structured schema/entities. More details of the proposed solution can be found on the developer community post. We would love to understand if these improvements address some of your concerns and pain-points in using the current Forge storage API.

Current Board
This one is probably is a quick win, it’s just one of many that the teams working on Jira are prioritising alongside extension points, REST APIs etc. I see Sam has raised this on the community before and we’re tracking demand on FRGE-485.

Migration
This quarter we’re exploring how we can better support remote compute from Forge with a plan to build out those capabilities in the first (calendar) quarter next year. Among other things, the scope will likely include remote access to Forge storage.

As some of our designs/plans around big initiatives like storage and remote access are clearer it would be awesome if we could run them by you and your team to get some early feedback. Would it be OK if we reach out in the not-too-distant future?

Thanks again, Adam

2 Likes
3

Hi Adam,

Thanks for addressing those points, feel free to reach out whenever, I’m sure the team/I would love to give feedback

Cheers, Nick

1 Like
4

Thanks for getting back to us Adam. That means a lot to us.

re: Migration. The question is not so much the ingress of data, but how we know who owns what data once it is migrated. This is an area which is unknown to us at the moment. Do you have any thoughts on it?

Thanks

Dave

5

When you say who owns what data, do you mean which site/tenant the data belongs to? And how we would prevent cross-tenant access?

6

Mostly the former, Adam. We would need to be able to migrate our data so it is a seamless experience for the customer. Cross-tenant access would be another issue.

7

Understood. Still a bit early to have an answer at the moment but I’ll reach out for a chat in the not-to-distant future.