Connect App Descriptor: hosting UI and API components on different URL's

The documentation for the Confluence Space Tools Tab module (at Space Tools Tab) has the following description for the url parameter: “The url to retrieve the content from. This can be absolute or relative to the add-on’s baseUrl”.

From this description, it was my understanding I could use an absolute url different from the baseUrl of the app descriptor. The reason I like to use an absolute url for this (or any other) module is because I want to host the UI components of my app on one location and the API on a different location (both are deployed separately). So the descriptor would look something like:

{ "baseUrl": "" "lifecycle": { "installed": "/lifecycle/installed", ... } "modules": { "spaceToolsTabs": [ { "url": "" ... } ] }

However, when using an absolute url for the Space Tools Tab module and loading the page in Confluence, a 500 error is thrown. When this url is relative, the error is not thrown. So I assume the documentation is a bit misleading and having an absolute URL different from the baseUrl is not supported?

To make my question more general: is hosting the UI and the API of an app in different locations supported? And if so, how is this best approached (from perspective of the app descriptor)?

Thanks a lot!

I’m afraid that in this case the problem is that a generic documentation is used by the generator. The url property does allow absolute urls in some situations, for instance web items that have a context addon. However, is does not work for this specific module.

You can still host your UI elsewhere, given that your UI is a React/VueJS/Svelte/etc type of app. You can load the javascript from a CDN. As long as the index.html is coming from a location relative to the base URL in the app descriptor.

1 Like

Thank you for your reply @remie. That is quite a bit of a bummer. Having the index.html available as part of the API builds/deploys and splitting out the other frontend assets (to serve over CDN) just complicates matters a lot. I would like the entire UI (including the index.html) to be built and deployed to a CDN as an independent self-contained package. This seems like such a common use-case.

The only option to maintain this independence between UI and API would involve putting some kind of reverse-proxy in front of both it seems, but that would nullify the CDN benefits.

Technically, you could probably also use an API endpoint as the url and have that return a 302* redirect to the index.html in your CDN

*) Make sure not to use 301 because this is cached indefinitely by the browser and will not allow you to change the location unless you want to tell all your customers to reset their cache.