Check if the extra iframe is really necessary for the microfrontend-broker communication #14
Assignees
Comments
danielwiehl
added a commit
that referenced
this issue
Dec 9, 2021
16 tasks
danielwiehl
added a commit
that referenced
this issue
Dec 9, 2021
danielwiehl
added a commit
that referenced
this issue
Dec 9, 2021
danielwiehl
added a commit
that referenced
this issue
Dec 10, 2021
danielwiehl
added a commit
that referenced
this issue
Dec 10, 2021
The idea of this extra communication iframe was to strictly separate the communication between platform and host application and to allow multiple connections from a microfrontend. Since multiple connections from a microfrontend are a very hypothetical construct and the strict separation cannot be leveraged for library integration (e.g. SCION Workbench), we decided to remove this extra iframe. This cut the number of iframes in half, eliminated a communication hop, and drastically reduced the complexity of client-broker communication. closes #14 BREAKING CHANGE: Removing the gateway iframe in client-broker communication introduced a breaking change in the host/client communication protocol. You need to upgrade the version of SCION Microfrontend Platform in host and client applications at the same time. The breaking change refers only to the communication protocol, the API of the SCION Microfrontend Platform has not changed. To migrate, upgrade the `@scion/microfrontend-platform` dependency of host and client applications to version `1.0.0-beta.20`.
danielwiehl
added a commit
that referenced
this issue
Dec 10, 2021
The rationale for this extra gateway-iframe was to create a separate namespace for the platform and the host application in terms of communication and capabilities, and to allow multiple connections from a microfrontend. But, in libraries such as the SCION Workbench, we cannot hook into the platform's internal namespace. Further, multiple connections from a microfrontend are a very hypothetical construct. Therefore, we decided to remove this extra iframe, which halves the number of iframes, eliminates a communication hop, and drastically reduces the complexity in the client-broker communication. closes #14 BREAKING CHANGE: Removing the gateway communication iframe introduced a breaking change in the host/client communication protocol. You need to upgrade the version of SCION Microfrontend Platform in host and client applications at the same time. The breaking change refers only to the communication protocol, the API of the SCION Microfrontend Platform has not changed. To migrate, upgrade to the newest version of `@scion/microfrontend-platform` in the host and client applications.
danielwiehl
added a commit
that referenced
this issue
Jan 31, 2022
The rationale for this extra gateway-iframe was to create a separate namespace for the platform and the host application in terms of communication and capabilities, and to allow multiple connections from a microfrontend. But, in libraries such as the SCION Workbench, we cannot hook into the platform's internal namespace. Further, multiple connections from a microfrontend are a very hypothetical construct. Therefore, we decided to remove this extra iframe, which halves the number of iframes, eliminates a communication hop, and drastically reduces the complexity in the client-broker communication. closes #14 BREAKING CHANGE: Removing the gateway communication iframe introduced a breaking change in the host/client communication protocol. You need to upgrade the version of SCION Microfrontend Platform in host and client applications at the same time. The breaking change refers only to the communication protocol, the API of the SCION Microfrontend Platform has not changed. To migrate, upgrade to the newest version of `@scion/microfrontend-platform` in the host and client applications.
danielwiehl
added a commit
that referenced
this issue
Jan 31, 2022
The rationale for this extra gateway-iframe was to create a separate namespace for the platform and the host application in terms of communication and capabilities, and to allow multiple connections from a microfrontend. But, in libraries such as the SCION Workbench, we cannot hook into the platform's internal namespace. Further, multiple connections from a microfrontend are a very hypothetical construct. Therefore, we decided to remove this extra iframe, which halves the number of iframes, eliminates a communication hop, and drastically reduces the complexity in the client-broker communication. closes #14 BREAKING CHANGE: Removing the gateway communication iframe introduced a breaking change in the host/client communication protocol. You need to upgrade the version of SCION Microfrontend Platform in host and client applications at the same time. The breaking change refers only to the communication protocol, the API of the SCION Microfrontend Platform has not changed. To migrate, upgrade to the newest version of `@scion/microfrontend-platform` in the host and client applications.
danielwiehl
added a commit
that referenced
this issue
Jan 31, 2022
The rationale for this extra gateway-iframe was to create a separate namespace for the platform and the host application in terms of communication and capabilities, and to allow multiple connections from a microfrontend. But, in libraries such as the SCION Workbench, we cannot hook into the platform's internal namespace. Further, multiple connections from a microfrontend are a very hypothetical construct. Therefore, we decided to remove this extra iframe, which halves the number of iframes, eliminates a communication hop, and drastically reduces the complexity in the client-broker communication. closes #14 BREAKING CHANGE: Removing the gateway communication iframe introduced a breaking change in the host/client communication protocol. You need to upgrade the version of SCION Microfrontend Platform in host and client applications at the same time. The breaking change refers only to the communication protocol, the API of the SCION Microfrontend Platform has not changed. To migrate, upgrade to the newest version of `@scion/microfrontend-platform` in the host and client applications.
mofogasy
pushed a commit
that referenced
this issue
Jan 31, 2022
The rationale for this extra gateway-iframe was to create a separate namespace for the platform and the host application in terms of communication and capabilities, and to allow multiple connections from a microfrontend. But, in libraries such as the SCION Workbench, we cannot hook into the platform's internal namespace. Further, multiple connections from a microfrontend are a very hypothetical construct. Therefore, we decided to remove this extra iframe, which halves the number of iframes, eliminates a communication hop, and drastically reduces the complexity in the client-broker communication. closes #14 BREAKING CHANGE: Removing the gateway communication iframe introduced a breaking change in the host/client communication protocol. You need to upgrade the version of SCION Microfrontend Platform in host and client applications at the same time. The breaking change refers only to the communication protocol, the API of the SCION Microfrontend Platform has not changed. To migrate, upgrade to the newest version of `@scion/microfrontend-platform` in the host and client applications.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
Each microfrontend uses an extra iframe to communicate with the broker. While an extra iframe may be required in the host application for correct dispatching of intents to the host application and host platform, it may be redundant in microfrontends.
Describe the solution you'd like
Microfrontends already run in a dedicated iframe, so it should be examined if this extra iframe is still needed for microfrontends. Because using a separate iframe for communicating with the broker doubles the total number of iframes in the application.
The text was updated successfully, but these errors were encountered: