You’re right, the limits imposed are currently arbitrary. To protect our platform, we need to impose upper bounds which is why this exists. We want to set the limits for GA based on the requirements from our developer community, so this kind of information is really valuable to us.
To help me understand a little more, do you think there is a reasonable limit that can be imposed, or do you think it varies significantly? We’d be happy to consider changing things based on feedback.
In terms of serving your own assets, we are currently considering this possibility. It may, however, mean that users need to consent to it as it can provide a means of data egress.
Well it really depends on the app and what libraries it’s using. One of my react based apps is around 350 files - and it’s not that advanced on the client side (it’s got some bells and whistles - but not that huge).
My suggestion would be to start with a “target” with the huge blinking sign with “we will change this depending on what we see” and then start measuring what people are doing… 'cause you give me a limit - I’ll come up with a way to work around it…
That said - I would poll the vendor community with the more interesting apps on the client side and ask them about their apps. It would be good though for an explanation of what a bundle really is from you and how you see them being used…
I don’t have any forge specific cases right now that would exceed the limits, but a number of our more complex apps would exceed both the 10mb and 1000 file limits. It is the kind of thing that would indicate that Forge isn’t ready for real apps, and we would hesitate to bet too much on it from a technical strategy perspective.
As a data point, the FE build for one of our apps comes in at 20MB and several hundred files. The app consists of a SPA settings management app in a connect general page, several issue panels and glances built using AtlasKit. The bulk of the weight comes from Atlaskit and its dependencies along with assets and a large 3rd party library.
Hey @dzagorovsky—I think it’s worth clarifying a few points.
Connect UIs only support a single extension point in the native apps—the Jira issue glance. This is the only place where any app can be viewed on native apps right now. That means that UI kit and custom UI also don’t support native apps at all.
We don’t have any concrete plans to support the native apps right now other than a broad intention to do it eventually.
I’m hitting a road block trying to create an integration with a custom UI. Due to the restrictive CSP, I am not allowed to put iframes to other websites (like an embedded youtube video for example) into the custom UI.
Would it be possible to have a more permissive frame-src in the CSP, seeing as how they are already isolated? I suppose that allowing all hosts might be contrary to the goal of preventing XSS, but maybe we could have a way to define explicit exceptions?
We are currently exploring ways to increase the flexibility of Custom UI CSP policies whilst at the same time maintain our security and trust goals with Forge. At this point, we can’t provide any concrete answers, although know that it is actively being worked on.
If you’d be interested in talking about your use case in more detail with my team, we can set something up. We’d love to hear more about what you are trying to accomplish.
@danielwinterw I am curious if there is a way to get the context from Custom UI without making a call to a resolver?
I just re-watched some of the sessions from Developer day and it seems Pete’s example (screenshot below, lines 26-27) is reading the context from window.location.search. Is there any documentation on this?
I think a possibility to show fullscreen Custom UIs (adminPages, jiraProjectPages or at least a fullscreen modal) is urgently needed. Confluence offers this for Atlassian Connect and Forge Custom UI. Currently Jira Custom UI does not offer a single possibility to show larger configuration pages for complex add-ons or a fullscreen page for like project-summaries.
My guess is that adminPage and projectPage (both available in Connect) are the key features that will prevent many Connect apps from migrating to Forge:
Simply from a UI perspective the available Forge modules are just to small. Missing space for complex configurations.
All available Custom UI modules in Jira are just “issue-scoped” (IssueGlance, IssuePanel, IssueAction…) – no possibility to allow project-summary-like features.
The available Custom UI modules are visible for everyone. No admin-pages. No conditions (whether to show a menu item).
Given that Forge Custom UI is the future for AMP apps, I think these are the key roadblocks for many vendors. The most popular marketplace apps rely on the mentioned Connect-modules which are currently missing a Forge-alternative.