Cheers, great feedback @jbevan
Regarding:
- Webhooks/events: Yeah we’re definitely going to take the learnings from Connect webhooks and apply the same thinking to Forge Remote. It makes a lot of sense to keep them the same.
- API rate limits: Yep, it makes total sense to keep them the same.
- Storage/Webhooks rate limits: We haven’t thought this far ahead yet, but perhaps we’ll reach out for feedback when we’re further down the road
- Long live URLs: Yep, makes sense
- Observability/traceability: Good timing, we’re discussing this at the moment actually. The plan would be to capture the remote invocations in the Forge logs so you’d be able to see errors, view metrics in developer console etc. The outbound requests also include a unique
traceId you can use to to trace requests from Forge to your remote.
2 Likes
@AdamMoore and @SushantBista, I don’t follow the reasoning here. Are you saying that customers’ needs for data residency would be satisfied when Forge’s data is resident in the customer regions? How will the “remotes” know where to process data?
2 Likes
Developers will be able to specify different remote URLs for each region they support as they do in Connect. The invocation service (which will be running in the customer’s region) will route requests directly to the appropriate URL for that region.
So, if the app is only doing remote compute (and not storage) then it could meet a customer’s need for data residency at that point.
For full data residency support (including remote storage) we’ll need a similar suite of capabilities as Connect (realm migration hooks etc). Probably something worthy of its own RFC at some point.
6 Likes
Hi Sushant,
Thanks for the update. I cannot find a public Jira ticket for Forge data residency in your ecosyste.atlassian.net Forge project. It would be nice to have a Jira ticket that we can watch in order to followup on your progress. Could you create one or give us a link if there is a existing Jira ticket?
Thanks
1 Like
Hi @dusan.spaic, I have created a FRGE Jira ticket. Generally, any major project status updates (e.g. target timeline etc.) will be updated on the public roadmap Trello ticket, so I would recommend to watch that ticket as well. Thanks!
Hey @richard.white thanks for the feedback, sorry for the slow reply.
We have use cases for our apps where we would like to call Atlassian API’s on a schedule - that could be days or even months apart. However, we do not want to store very long lived credentials if we can avoid it
Just thinking out loud a bit… I wonder if this is a use case for remote Forge scheduled triggers? Perhaps you could set up a daily scheduled trigger that makes a call to your remote with short-lived access tokens (similar to product events in milestone 2). If you don’t need it on a particular day could ignore it but you’d be able to call Atlassian APIs at least once a day without storing any credentials.
And yeah, milestone 3 is probably the biggest overlap between Connect-on-Forge and Forge Remote so we’ll need to provide more clarity and guidance here.
3 Likes
Perhaps you could set up a daily scheduled trigger that makes a call to your remote with short-lived access tokens
Yes - I think this would work for us - in general being able to have authenticated calls to the remote “on demand” from our forge backend functions would mean we would never need to store credentials outside the scope of a single event / request.
1 Like
I agree with everybody here; this is awesome and will unblock a lot of things, including making it a lot easier to progressively migrate to Forge from Connect.
What do you think about the order of priorities?
For us the right order is: 1, 2, 3, 5 (I don’t see any usage for 4 right now)
Are there any use cases you don’t think we’ve covered?
It is unclear to me where the ability to call our remote backend from Forge backend sit in this? Did I miss something, or it is not in this roadmap?
Would you have a preferred way to receive long-lived API credentials?
The current Connect mechanism, aka an installation trigger that send us an App/instance specific long live token used to request a shorter token, seems the right way to me.
I have a question about the context_token, what info could we extract from it?
CloudId? AppId? environment id? instanceUrl/baseUrl/siteUrl? userId?
Documenting this early one and making sure it is coherent between the different type of calls/triggers will simplify things.
Behind this question is the need to correlate the data between the Connect part, identified by the clientKey and the Forge part, identified by … the cloudId I suppose.
Right now, we use the siteUrl in the install trigger to call our backend with a hardcoded token to make the link between the clientKey and the cloudId base on the URL … A better mechanism will be good.
2 Likes
Hey @SilvreLestang, thanks for the response.
It is unclear to me where the ability to call our remote backend from Forge backend sit in this?
Yes, a few commenters have mentioned this so it’s another milestone to add to the mix. Compared to the others, I think it would be relatively low effort so we’ll look to include early in the roadmap if we can.
I have a question about the context_token , what info could we extract from it?
You’ve touched on a really important point here. This is probably one of the main things I want to collaborate on and get feedback on during the EAP. The various ids will be similar to what is currently available in Forge’s app context. One thing we want to introduce is a single id (installationId maybe) that you can key data to without having to build or decompose other ids like you need to currently in Forge.
The relationship with clientId is also something we need to solve but we’re not sure exactly what that looks like yet.
4 Likes
For us the important parts are milestones 1 and probably 4, though only transitionally. Our use case is an app that was built on Connect because Forge didn’t exist yet, but that we think can be migrated completely to Forge. (We’d like to do that so we can stop worrying about hosting for the backend.)
The blocker that is relevant to this RFC is that we already have a lot of users who have a lot of configuration data in our backend. Anything other than seamless automatic migration is implausible from a UX point of view.
In our case, the (aspirational) plan is to first move most of the app to Forge using something like milestone 1 to keep loading the configuration data from our backend. Then, we would use something like milestone 4 to migrate the existing data into Forge storage. Finally, we would just get rid of the legacy backend and the Forge Remote part will no longer be used at all.
1 Like
Thank you for such a detailed description!
What do you think about the order of priorities? Are we building the most useful functionality first?
Stages 1, 3, and 4 are the most important for us. The order of implementation meets our needs.
I have nothing to add to the suggestions that have been made about the other questions. I just want to emphasize the importance of these developments for us. We are looking forward to using them in our applications.
1 Like
Thank you very much @AdamMoore for this very detailed RFC and also for being so active in the thread!
This looks very promising to us.
What do you think about the order of priorities? Are we building the most useful functionality first?
Having milestone 1 to 3 implemented (or 2 replaced by “Forge function to Remote”) would allow us to migrate all of our apps to Forge. So for us the order is fine 
Would you have a preferred way to receive long-lived API credentials?
The Connect (credentials via an installation hook) would be fine for us.
4 Likes
Hey everyone,
Thanks for the overwhelming response to this RFC. There have been lots of great suggestions that will help us shape the roadmap in the future.
Firstly, great news, we’ll kick off the EAP for milestone 1 in the next week or two. If you’re interested, please register at go.atlassian.com/forge-remote-eap. You’ll need to provide the id of one of your test apps so we can set you up.
I appreciate milestone 1 on its own won’t unlock a lot of use cases, but I’d still encourage you to join. Many of the design decisions we make now will carry over to future milestones. The earlier we can get feedback the better.
As for the ordering of future milestones, the only thing I know based on feedback so far is that they’re all important We’ll do a bit more investigation on the effort involved in each milestone and feed that into our decision too. There’s a good chance we’ll bring M4 (storage) sooner. We will also add “Forge function to remote” as a milestone somewhere too.
Let’s keep the discussion going in the EAP. Talk soon!
7 Likes
Hi again,
Just a quick update on the EAP.
We now have functionality for milestones 1, 2 and 4 available to try. That’s:
- Remote backends for Forge frontends
- Remote delivery of product events (webhooks), and
- Remote access to Forge storage.
One thing we’re learning is that the nuance around the config and contract is really important and we’re still keen to get as much feedback as possible.
If you haven’t already joined it’s not too late to do so. Sign up at go.atlassian.com/forge-remote-eap .
Thanks!
4 Likes