Federation Discovery

[zackarychapple]

Short Description

Module Federation discovery is a methodology and series of tools that allows for the registration and discovery of federated remotes in a distributed team.

Longer Description

Module Federation service discovery is a service that allows for the discovery and communication between different modules in a distributed system. It is similar to the java library Eureka in that it allows for the registration and discovery of micro-services within a system. NPM and Docker hub could also be viewed as slightly similar as they are repositories with high discoverability and versioning. With module federation service discovery, each module in a distributed system can register itself as a federated remote, providing information such as its name, location, and any other relevant details. Other remotes can then discover these registered federated remotes and consume them as needed. This allows for a more efficient and organized way of managing the communication and interactions between different modules in a distributed system.

Business Value

Distributed teams are frequently creating new federated remotes, exposing them within their organization, and consuming them in their known use cases. Additional use cases may exist within an organization and teams may duplicate effort due to the fact that the exposed module is unknown and not easily discoverable.

Acceptance Criteria

TBD

[zackarychapple]

When this was as an issue the following messages were on it before we moved to discussion.

from @RussellCanfield

@zackarychapple - I was thinking of something similar myself, an enhancement to the MF Dashboard package that is out there. The enhancement would show dependencies of a federated module (react, material, etc) and their versions. Also what shared modules it was configured for.

The initial thought was to catch drift between modules that may break sharing compatibility or prompt for updating to a specific version (maybe a vendor module bug fix). I think a further enhancement would be leveraging something like Storybook perhaps, just a sort of live documentation that is source controlled/deployed with the actual federated module. Just wanted to contribute my thoughts :)

[zackarychapple]

@zackarychapple replied

@zackarychapple - I was thinking of something similar myself, an enhancement to the MF Dashboard package that is out there. The enhancement would show dependencies of a federated module (react, material, etc) and their versions. Also what shared modules it was configured for.

In the coming updates with Medusa (the new brand for the Dashboard) it will have this information along with bundle size and other telemetry. I think as you mentioned though knowing what is coming with the federated module in terms of dependencies and requirements would be valuable for a service discovery. @vitorbergamo is managing the roadmap for Medusa and will be creating some similar RFC's as well.

The initial thought was to catch drift between modules that may break sharing compatibility or prompt for updating to a specific version (maybe a vendor module bug fix). I think a further enhancement would be leveraging something like Storybook perhaps, just a sort of live documentation that is source controlled/deployed with the actual federated module. Just wanted to contribute my thoughts :)

This is great feedback. It makes sense and would be high value to be able to see. There is another RFC that @viktoriialurie will be adding in the near future around generating Storybook automatically. This may be something that requires using Nx though but that discussion can happen in that RFC.

[zackarychapple]

There is some very interesting work being done around a schema for this by @joeldenning, @lucamezzalira, @matteofigus, @ScriptedAlchemy here.

[tysonrm]

See the Aegis application fabric, which is a self-forming service mesh that uses multicast DNS for service discovery. One node in each multicast group is designated as the "switch" node, which answers the other nodes' mdns queries looking for the switch service. The switch answers with its ip, protocol, and port and the nodes connect to it over websockets on the same port as the REST API. The switch node then acts like a network switch broadcasting any events it receives to the other connected clients. It also has routing logic that supports load balancing, call response, subscription, targeted service and event consumption. This is done in support of the distributed cache and distributed workflow features. The switch designates one of the connected nodes as the backup switch. Any Aegis host can become a primary or backup switch node. The service mesh employs a pluggable architecture which enables any broker to serve as a switch node, such as DDS, Kafka, RabbitMQ, NATS, etc. The fabric has been tested with NATS and Kafka. FInally, switch nodes can be configured with an uplink to other app fabric networks.