Move embedded custom visualization UIs into the app?

[j08lue]

Three GHGC datasets require different visualization tools than standard Exploration:

1. EMIT
2. NOAA CO2 and
3. NOAA CH4

Currently, we provide this customized exploration functionality via an iframe-embedded external UI built for the purpose.

However, iframe-embedding is generally discouraged for official sites and the user experience is also not great.

We need to revise how we provide custom exploration functionality within VEDA UI. Perhaps as a standalone, full-width exploration that replaces the standard Exploration for these datasets. TBD.

As a first fix, would it be possible to move the custom UI code into the Dataset page or somehow else ship it with the app?

Acceptance criteria

• [x] Assessed whether there are any quick ways to get rid of the iframes

[nerik]

Following up on this as well as @amarouane-ABDELHAK feedback on Slack:

The security risk associated with iframes is minimal since we maintain/develop the content of the iframe. The other concerns are:

• The potential CORS issues when making service requests from within the iframe context
• The performance of the webpage (because the overhead HTTP requests to make the iframe contents work)
• The click detection, downloads and user behavior will be challenging to gather within the iframe

For context, the iframes / <Embed> block solution was not meant long-term solution, but rather as a decent quick fix for a pressing need from both the EIS team and the GHG center. It allowed us to quickly iterate, provide an okay solution to users, and assess their needs. Addressing @amarouane-ABDELHAK points:

• considering IMPACT controls both iframe host and content, we can always set up a CORS policy fitting our needs. It might be a problem in the future should that change;
• that's a fair point. We're loading an extra html page but more importantly we're loading a bundle with another copy of Mapbox GL JS;
• AFAIK we don't have that kind of granularity in our Analytics anyways, but a potential limitation in the future too.

Maybe now is a good time to discuss the long-term solution. We haven't quite yet decided on three possible trajectories that are not using iframes:

1. Fully independent apps only accessible through a link;
2. Allow for fully custom applications living within an instance;
3. Progressively integrate functionality identified as needed for the custom visualisations into the veda-ui core (arbitrary Mapbox GL layers, map popups, time range selector, etc), configurable through MDX.

In the meantime, would it make sense to at least host those apps bundles into the static folder of veda-config-ghg, meaning the iframes would be same-domain?

cc @hanbyul-here

[j08lue]

Thanks for the overview, @nerik!

In the meantime, would it make sense to at least host those apps bundles into the static folder of veda-config-ghg, meaning the iframes would be same-domain?

I think yes, at least for GHGC. It is not pretty, but in the case of the GHGC, these apps are integral parts of the UI, not external tools, so from a coherence and dependency management perspective, it would make sense to have that code included, while we work on better solutions.

What do you think, @slesaad?

[slesaad]

I was thinking of creating a different but single repo for all the custom interfaces and then hosting them under the same domain (using Cloudfront), but what @nerik suggested essentially solves the problem in a much simpler way. Like it!

[amarouane-ABDELHAK]

In the meantime, would it make sense to at least host those apps bundles into the static folder of veda-config-ghg, meaning the iframes would be same-domain?

That will be a good work around. But, how about not using iframe but use embed HTML tag?

[hanbyul-here]

What are the advantages we can get from embed tag? As far as I understand, iframe is a more common practice to sandbox HTML, and embed seems to be encouraged for other types of content such as PDF: https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Other_embedding_technologies#active_learning_classic_embedding_uses But please let me know if there is anything I am missing.

[amarouane-ABDELHAK]

You are correct that embed is commonly used for multimedia. But, when I was playing with EMIT app (for a prototype), it appeared that embed did integrat seamlessly without the need for additional CSS to remove borders or make adjustments. Here's an example from W3Schools: And this the prototype using embed (without any extra CSS)

This is not a hard requirements it is just a suggestion. As mentioned, the only potential advantage of using embed vs iframe is that it gives a more native appearance to the HTML page."

[amarouane-ABDELHAK]

But off the record I just want to answer with a hard no if asked "does this website uses iframes?" since lots of people don't like it.

[nerik]

@slesaad

I was thinking of creating a different but single repo for all the custom interfaces and then hosting them under the same domain (using Cloudfront), but what @nerik suggested essentially solves the problem in a much simpler way. Like it!

Actually, your solution is much better - I completely overlooked that these custom interfaces are not vanilla js but instead bundled with webpack. So doing like I suggest either implies

• modifying the bundle process already in place in veda-config-ghg to allow bundling each app in parallel, which feels very overengineered
• or building the apps locally and moving the bundle to the static folder manually, which is very brittle. (I gave it a try here)

So I suggest we move ahead with the Cloudfront solution.

[j08lue]

Aside from the iframe controversy, there is a very simple concern for the GHG Center web presence at play here: Since it is to be an authoritative, reliable, reviewed and vetted source of information, all the content and tools we present should look and feel authoritative.

Where some parts of the platform are hosted and how they are embedded / connected is a less important technicality, as long as

1. we control that source and
2. users do not stumble over links like https://nasa-impact.github.io/noaa-viz - which could lead them to think that this content is less authoritative or reliable.

Therefore, let us please

1. Leave the choice between iframe and embed be a purely technical one - if iframe is standard and embed would be an uncommon choice, let's keep iframe until there is a organizational explanation against it.
2. Host the external apps anywhere that works well for us - if GH pages, perhaps move them to the GHGC GitHub org, though - and prettify the links with CloudFront.

That is, to me, a viable solution for the GHG Center and we can in the meantime work on designing a solid approach to make these UIs a more native part of the app.

[j08lue]

Hope we're ok with the decision above and can move on to the implementation ticket I created.