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.
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!
Hi Athan
Can I be part of it? It would help me a lot
Thanks
Paul
- I am Adarsh, Product lead for Forge. I recently joined the Forge team having spent 4+ years building Atlassian Identity platform. Thanks @tobitheo and team for exploring Forge in depth and sharing back your findings with the community. This thread has a ton of great feedback for the Forge team and we are already actioning on some of them. Post like this is great for us to understand the challenges faced by developers and helps us immensely to prioritise the right things to build and ship to make Forge better.
Let me attempt to share some of our thoughts on key items in the feedback;
UI Kit vs Custom UI vs Connect
When we embarked on building Forge, we created UI kit to support apps natively within our products. It was designed to be declarative and closer to products compared to what we have today in iframes. We know UI kit is limited in it’s current form, that’s why we still have the beta label. Over the last year we reduced our investment into UI kit to focus on the launch of Custom UI which was an essential piece in unlocking Forge for real world usage. We knew that we needed to do this first, before continuing on our longer term goals for UI kit.
Interactivity in UI kit is a known point of friction for both developers and end users. We’re not focusing on increasing the 10 second restriction. We believe that 10 seconds is too long for a user to wait for UI. What we are beginning to focus on is how to solve interactivity on the whole. The main area we are currently exploring is a client side runtime for apps. Rather than requiring a FaaS roundtrip invocation for every button press, we’re exploring what it would look like to execute your apps code within the browser. One question we are looking to answer is what it would mean to use real React, instead of our React inspired syntax. There are some obvious challenges in doing this, but we are seeing promising results and are evaluating next steps.
It’s likely that UI kit will change significantly. We’re just not sure exactly how this looks yet.
On Custom UI:
Thank you for your feedback on the Forge tunnel. This feedback has been passed on to the team.
We like to use Typescript for all of our Node and web-related projects these days. Javascript is nice for quick scripts, but as soon as projects become even a bit bigger, using Typescript just helps soooo much with so many things
As you’ve correctly surmised, we’re huge fans of Typescript at Atlassian. In Ecosystem Platform we haven’t used Node.js for any new services for quite some time. And our preference would be that Marketplace Partners are using Typescript too, due to the increased productivity and almost certainly lower number of runtime errors that will bite our mutual customers!
The reason the majority of the templates are vanilla Node.js is that we decided we wanted our templates to be usable by as broader base as possible. A Typescript developer will have no problems understanding a Node.js template—even if the lack of type-safety is deeply distasteful 
—whereas a Node.js developer unfamiliar with Typescript may have a hard time following one.
Ideally we’d have TS / JS variants of each, but as you’ve seen our current templates are rapidly outdated as we improve the Forge platform. We are planning on figuring out a more sustainable way to maintain these, as they are a pretty key aspect of our onboarding experience.
I love the BYOT idea! And thank you for your contributions (and the to-the-point license 
). We’ll see if we can sneak that into an upcoming CLI release.
As for cryptographic operations, we have found that jsrsasign works well for us
Thanks for the report around the conflict between crypto and snapshotting, and the tip about jsrasign as a workaround. We’ll investigate the bug and resolve it if technically feasible, or at least improve the error and document the limitation if there are fundamental issues with snapshotting the crypto package.
Regarding the reset of variables between function calls, that is by design and put there to prevent cross tenant data leakage. The same Forge function is executed for multiple customers. I.e. If your App is installed by multiple customers, all the invocations for those customers go to this single Forge function (although this will scale dependant on load). To prevent the case where an App accidentally stores customer data in a variable outside the function (i.e. global), Forge resets all state, and thus those variables.
Great feedback on Forge’s storage API!
You’re right – it is currently a relatively simple key/value store. The good news is we have work underway that will enable Forge developers to specify schemas for their data, so we can offer validation before persisting. You can expect to see this land in the medium term. We have other types of storage on our longer term radar – in particular blob storage and relational data storage – but those are less concrete at the moment. We’re very keen to hear about cases where the current datastore is a blocker in practice – this will help us tune those future plans.
On the topic of storing secrets, it looks like this has been covered in the discussion already, but in short: the reason we don’t recommend storing secrets is that we don’t yet offer all the features you’d need to do so easily and safely. If you choose to store secrets, you’ll need to take on the responsibility of encrypting the data before persisting, and having a solution in place for rotating your encryption keys. So it’s doable today, but is more complex and risky for developers than we’d like, hence our recommendation to hold off for now if possible.
We believe one of the primary use cases for needing to store credentials is to make authenticated calls to external sites. The good news here is that, as you say, we’re currently working on a feature for calling out to OAuth 2.0 sites (expected within the next few months) and will subsequently look at solutions for other forms of outbound auth.
A lot of things related to Jira Service Management projects right now are broken: There are no events for those projects and its data can not be accessed via REST API. This is apparently due to Forge not supporting any of the scopes necessary to use JSM projects.
We want to support JSM on Forge, we are investigating this internally and will updates the thread once we have more details.
Thanks for your ideas on scoping! They’re timely, as we’re currently undertaking some design and security explorations into how administrators and users perceive scopes, and how developers use them. It’s encouraging to hear that we’re on the right track! We are investigating making them more granular though—but we’ll strive to not go overboard and maintain our balance between customer privacy and developer convenience.
This is a well known problem to us regarding Forge, and one that we’re looking to rectify, as there are certainly plenty of use-cases for impersonating users in a non-UI context. Invoking a REST request as a user isn’t supported in non-UI contexts because we don’t currently have a way to consistently ask the triggering user for consent. ACT_AS_USER in Connect does not require end-user consent, and therefore does not suffer from this problem. There are certainly ways to solve this, and we’re have considered evolving our auth model to support impersonating users in more contexts. The jury is still out at this stage on user selection, as it’s a fairly powerful feature that’s ripe for abuse. It may be something that we can protect with an additional scope though.
Limited Selection, For Now
We are glad that you align with the simplified approach we have taken towards modules in Forge. The difficulty surrounding the use of web items as you have mentioned was one of the main reasons for designing Forge in this way.
Although less flexibility in the immediate-term comes as a result of making this decision, in the long term, we will not only improve Forge’s module-parity with Connect, but also introduce new extensibility options that would not have been possible on the Connect platform (even through web items and web panels). Recently, we have done an extensive study in an effort to narrow the extensibility gap by prioritising Forge equivalents of Connect modules that have the highest usage - we just shared an update on Forge modules that have equivalent modules in the Connect framework. Also keep an eye out for a blog post on this on our Developer Blog in the coming week with more details.
Atlassian has not yet found a proper solution to migrate a Connect app to Forge app with the same key on the Marketplace
We’ve specced out a solution to this problems outlined in the feedback and we will soon be reaching out to community to gather feedback.
Dynamic modules are not yet supported.
Not yet, but they’re on the harmonisation roadmap to be shipped in the initial quarters of next calendar year
Connect on Forge is not allowed to impersonate a user and make requests on the Jira API. In other words, ACT_AS_USER permission scope cannot be used.
Not yet, but scheduled to be replaced with similar functionality around Q3.
Big Thank you 
Thanks for providing detailed feedback on Forge, post like this re-instates the belief we have in our developer mission and help us to the build a platform, that is valuable for our customers, developers and all partners. We have multiple teams actively working on features across various parts of App development and this post acts as a benchmark for us to report back on all the progress we make in coming months. With this continued support and love from community, we will continue to learn, iterate and ship high priority features to ensure all builders choose to build their next App on Forge 
.
Thanks!
-Adarsh
This is awesome @asridhara (just as valuable as @tobitheo 's post 
) and super promising.
Quick question - when you say Q3 - is that Atlassian FY Quarters (ie Jan-Mar) or is regular Quarters (ie July-Sept) ?
@danielwester - Apologies for putting quarters out there. This is one of the priority items for harmonisation and currently planned within our yearly roadmap (Atlassian FY). As with any project, the timelines can vary based on the complexity we encounter but, rest assured we will share concrete timelines as we get more confident with our plan and delivery date.
First, great post. Thanks for sharing such detailed information.
I couldn’t agree more with this general assertion, of course, but one of the reasons that it’s useful to consider anyway is that the Atlassian products themselves do not always respond within this threshold. When put under load by the customer (for example when a customer adds a hundred or more macros to a Confluence page), the underlying products can not always meet this 10-second SLO, much less the code running in Forge that is waiting on it.
Also, while a UI action should never take 10 seconds to respond, the processing initiated by that action may very well take much longer to complete. So it’s imperative to support some sort of long running task mechanism. Currently all the server side lambdas are stateless and limited to that short window. If you have a long running operation half your time is spent waiting to load and save state which doesn’t leave you much time to actually do work.
Hi @asridhara
first and foremost: Thank you for your answer and sorry for my late reply.
My bad, corrected. I had not seen the appropriate section in the docs at the time for some reason 
Would agree with that in general. We could probably provide more contextual information to the user about what we’re waiting for at the moment, but the user might also not care, so idk.
I think the most helpful for the use cases we had might be a way to trigger re-evaluation of the function to show updated information, either periodically (for updating data from external backend services) or when there are changes to Jira fields the function depends on (like a comment, custom field or description change) or to form fields in the rendered output.
What you’re considering does sound promising and I’m looking forward to seeing what we’ll end up with 
In my opinion (!), the admin installing an app and giving consent for the app to do certain things on behalf of their users (i.e. what Connect does) should be enough. Some apps will be set up by an admin and then just work in the background on behalf of the users. We have several apps in the marketplace that fit this description. I’m happy to discuss this particular use case of ours with concrete examples further in private messages if you’re interested
Alternatively, it might also work to ask users for consent asynchronously via some kind of notification system so that when the app does need to impersonate the user in the background, it has this permission. But I have yet to think of a way that this could be implemented without most users just clicking it away because they have no context.
Other than those, what you write sounds very promising and I’m excited to see what will become of Forge. I think it has the potential to revolutionize the way app marketplaces in SaaS applications are handled in the future.
Big thanks and well wishes,
Tobias
periodically (for updating data from external backend services)
Hey @tobitheo, Currently we are working on a feature which enables Forge apps to push events to be processed asynchronously. Using this feature in our Forge apps we can break down large tasks into small tasks and push them as events to the Forge platform. Forge will then process those events and call the corresponding function in your app.
This way if there is a task, for example importing data from an external service, which could take more than 10sec. We can push multiple events to import only a small piece of data and store it in forge storage.
This feature is in active development and is expected to be released by next quarter.
Atlassian has not yet found a proper solution to migrate a Connect app to Forge app with the same key on the Marketplace.
Just sharing here in case anyone else is keen to follow the progress of this feature and perhaps even be an early adopter, but missed this announcement: