Resolution & Jexo Forge Hackathon Findings

What a fantastic write-up! Thanks for taking the time to share this. I just wanted to let you know that we actively monitor this entire community to try and understand the needs and problems that our developers face and everything in the post above is being broken down and incorporated into our planning process and roadmap. I can’t promise that we’ll fix everything tomorrow, but I do want to say that many of the concerns above we are actively working on.

From here, I’ll probably pull out individual sections from above and comment on them where I can.

When you deploy a Forge App these rough steps happen:

  1. You bundle your app code, via the Forge CLI, on your own machine.
  2. The CLI uploads it to AWS.
  3. Your deployment gets added to a queue.
  4. Your deployment gets picked up and provisioned in Atlassian infrastructure.
  5. The result of your deployment is sent back to you.

I just want to let you know that recently we poured some time into making step (3) significantly faster. This change was shipped at around June 4th. Now each individual deployer get’s their own virtual deployment queue. Everybodies queues run in parallel (to a maximum limit which is quite large) and within your own queue the deployments run sequentially. That means that, according to our metrics, most deployments, most of the time, see no delays due to queuing: the provisioning starts effectively immediately.

Screen Shot 2021-07-06 at 8.08.29 am

For “provisioning time” of your actual deployment (4), most of the time it takes around 20s to actually make happen. Some of that is out of our control as there are AWS restrictions, a few seconds are within our control and we may aim to make that situation better in the future though it is not a priority right now.

Screen Shot 2021-07-06 at 8.11.39 am

The message that I want to send is that, for most people, if you assume that when you run the forge deploy command that it will take around 20s that’s probably a good average guestimate for how long your deployment is going to take you. This obviously varies from app to app, deployment to deployment.

I also want people to know that we actively monitor this and are trying to make your development loop experience as fast as we possibly can. Speaking from personal experience, my Connect Apps that I host in EC2 take significantly longer than this. Only my “frontend-only” static Atlassian Connect Apps deploy at a similar speed. So Forge is certainly has the faster development speed for me.

I hope that gives you an interesting insight into our deployments at the moment and shows that the deployment process should feel and be significantly faster than when you ran your Hackathons. If you have any questions please ask away.


With respect to this, I can tell you that we did have a very lengthy discussion about this internally and it is still open to change.

What we knew, for sure, was that we would need the JavaScript examples, so we focussed on them first. This is because there are simply more JS developers than there are Typescript developers.

We were waiting for more feedback on the template options people chose to know wether or not to invest more in Typescript, maybe even getting to the point where every template was written in both Typescript and JavaScript. It’s really up to community pressure to get us there.

You could even use this comment as a proxy. If you want there to be a Typescript equivalent template for every JavaScript template then hit that like button. Then our PMs will use our various sources of data to make a measured decision.


Yeah, we are aware that this deviation from a standard Node.js development experience is not fantastic, but the performance wins from Snapshotting were just too good to not incorporate into the platform.

Our Smartlinks saw a 17% function invocation performance improvement on average (time reduction).

Some functions, especially code with larger bundle sizes, saw ~65% reductions in invocation times.

This is why we have Snapshotting on by default, it’s just too good to ignore. We hope that developers will be able to learn about, and work with the nuances this does place on the development experience. If there is anything that we could do to make it better, just let us know.


I have confirmed that this should not be the case, you should only be able to access App Storage while being inside a Forge function. You should not be able to go straight from Custom UI frontend directly to App Storage as a User. If you have found a way to do so, please send me a DM with the steps.

The intention is that only the App can access its own App Storage.

1 Like

Just tried it and it is indeed much faster. The deployment of my test app takes about 30s now and it also feels more reasonable now. Most of that is actually the upload, which is not saturating my internet connection for some reason. Maybe S3 is just slow :man_shrugging: We must’ve just missed the improvement with our hackathon happening a week before that.

I agree that snapshotting is worth it. This point in the writeup was really only to emphasize that the developer needs to be aware of it. I know that someone from the Forge team has documented this behavior and done a good job with it IMO. I’m not sure how it could be improved… maybe some error messages when our code is trying to access process.env during snapshotting if that’s possible?

You’re right, I did get this one wrong. I have corrected the post. Sorry :grimacing:

I’m not sure then: why aren’t we supposed to store secrets in Forge storage? Is it only the lack of encryption at rest? Couldn’t we just hardcode an encryption key in our Forge apps via environment variables and encrypt and decrypt the stored secrets? The environment variables are safe to use for secrets like API keys, right?


Yep, encrypted environment variables (forge variables:set --encrypt example) were designed for this exact use case.

The recommendation to avoid using Forge storage for credential store is because it currently isn’t designed for it over being a general purpose key/value store. The data is encrypted at rest but there’s currently no detailed audit log, ability to rotate secrets, admin visibility of secrets/ability to revoke, setting additional encryption context, etc. I’ll update to call this out.

Good question, it’s only part of the problem for credential storage. In this case your app would need to take on the burden of encryption key management, for example what happens if (when) you need to rotate the encryption key?


Good point. Hadn’t thought of that. It might be an okay solution until Atlassian ships the proper solution, but it’s all hypothetical for now anyway. Very helpful information! :+1:

Great conversation, thank you all for chiming in :slight_smile: This productive conversation was exactly what we had hoped this report would spark. Forge seems very interesting from a technology perspective and I we can probably roughly imagine how it works, but I would definitely watch a presentation on the inner workings if one were to be made at a future event :slight_smile:


Thanks so much @tobitheo, this is an incredibly thorough review of the platform and it was an absolute joy to read. Feedback is a gift and this page is especially so.

We’re eagerly following up on each of these insights and will address them cohesively soon – just following up amongst ourselves internally on a few bits and pieces first :running_man:

Thanks again!


@CarrieMamantov I’d like to petition for this post to be considered for codegeist even though it was posted a few days too soon if an exception hasn’t already been made. This feels like exactly the sort of post you were trying to encourage with the feedback and story telling prizes.


@rmassaioli I would like to chime in on this point and say that in my opinion good Typescript support or even better a TS-first approach is hugely important for Forge and should be a no-brainer - please read on.

In my opinion, deferring this decision to the community to wait and see who shouts the loudest is a pretty weak move. Atlassian should take the lead with this, set the standards and decide on their own what it takes to write enterprise-level apps and is best for the community and the ecosystem.

If Atlassian decides static typing leads to better software and better apps it should provide curated high-quality TS templates and great documentation to showcase what a basic high-quality Forge app looks like. I am convinced that the community will adopt and follow the lead - which will be for the benefit of everyone. However, this mindset has to exist within Atlassian otherwise it will not work.

To your point on which language has more developers, I think the point is irrelevant. TS as a superset of JS will very likely always have fewer developers. Following the same argument, I guess every TS developer can also be counted as a JS developer.

It is clear that I am sitting in the TS camp and I am happy to chat more about this. I have sent @JordanKoukides an email a while back (in response to his post) with some more concrete points and observations regarding the current state of TS support. I will copy those (slightly modified) below for reference.

Forge DX - TS support

… I have shared this before with other teams but I am convinced that precise typings for Forge are one of the key features to building enterprise-grade Forge apps. For my taste, the current typings still have way too many “any” references. This is convenient for Forge platform developers but does not help the end-user at all. In many cases, precise types can often compensate for lacking documentation.

To give you a concrete example:

The method getContext in the custom UI bridge is currently typed as () => Promise<FullContext> with FullContext being typed as FullContext = {}. As a Typescript developer, I am getting almost no type information from this declaration. I just also noticed that the docs on getContext contain a deprecation warning regarding the extensionContext property being deprecated. Again, if there were precise types for FullContext, then the extensionContext property could be marked as @deprecated and all Typescript library consumers would know that they should fix their apps.


@tbinna :100:
I also encourage full support of TS in every aspect of the Atlassian Ecosystem, whether it is Forge, ACE or AtlasKit


My thoughts on this are different: Please support javascript first. That’s the more widely used language.

1 Like

Is TS vs JS the new Tabs vs Spaces?

Seems like it. I’ll just add in that I hope that Atlassian doesn’t pick a side…

And if you do - I’m going to pitch Perl as the language of choice for Forge.

1 Like

I agree… don’t pick sides. Just add vanilla JS & TS examples. It’s not uncommon to show examples in multiples languages in documentation.

If you do decide to go for Javascript, please also remove all ES6 import statements, given that this is not natively supported by NodeJS. Basically any code that requires a transpiler (looking at you BabelJS) should be banned.

On a more serious note: Atlassian has picked sides before. They chose to use React for AtlasKit. All examples are in React. And Forge UI Kit is also React inspired. So Atlassian has taken sides before. They can do it again.

Wait, did I miss a memo? Has this been resolved?

Atlassian has not yet found a proper solution to migrate a Connect app to Forge app with the same key on the Marketplace

Right now we’re working towards supporting Connect on Forge apps on the marketplace, and I’m happy to report that our solution allows vendors to retain the same key when they decide to migrate their Connect app to Forge.


@Athan, Is the release of this still going to be next year or have the timelines moved forward?

We’ll be contacting eligible partners to participate in the Early Access Program gradually over the next 6 months. At this stage GA will be in the 2022 calendar year.


We would love to participate in the EAP!

1 Like