title: Communication pattern for MicroFrontends to MicroService backend trough single channel/websocket
body: <p>we are currently facing some tough architectural questions about integrating multiple <a href="https://en.wikipedia.org/wiki/Web_Components" rel="nofollow noreferrer">Web Components</a> with individual backend services in a composite web UI to one smooth web application.</p>
  
  <p>There are some constraints an (negotiable) design decisions:</p>
  
  <ol>
  <li>A MicroService should serve it's own frontend (WebComponent), we would like to use HTML Imports to allow including such a WebComponent to the composite UI</li>
  <li>A frontend WebComponent needs to be able to recieve live updates/events from it's backend MicroService</li>
  <li>The page (sum of Web Components used in the composite UI) shall only use one connection/permanent occupied port to communicate with the backend</li>
  </ol>
  
  <p>I made a sketch representing our abstract / non-technical requirements for further discussion:
  <a href="https://i.stack.imgur.com/9IAWq.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/9IAWq.png" alt="enter image description here"></a></p>
  
  <p>As of my understanding, the problem could be rephrased to: How do we</p>
  
  <p>a) concentrate communication on entering</p>
  
  <p>b) distribute communication on exiting</p>
  
  <p>the single transport path on both ends.</p>
  
  <p>This two tasks need to be solved on both sides of the transport path, eg. the backend and the frontend.</p>
  
  <p><strong>For the backend</strong>, I am quite hopefull that adopting the BFF pattern <a href="https://samnewman.io/patterns/architectural/bff/" rel="nofollow noreferrer">as not only described by Sam Newman</a> could serve our needs. The right half (backend) side of the above sketch could then look similar to this:
  <a href="https://i.stack.imgur.com/U2T8s.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/U2T8s.png" alt="enter image description here"></a></p>
  
  <p><strong>The transport path</strong> might be best served using standardized web technologies, eg. <strong>https</strong> and <strong>websocket (wss)</strong> for the most times needed, bidirectional communication. I'm keen to learn about alternatives with an equivalent high adoption rate in the web technology sector.</p>
  
  <p><strong>For the frontend</strong> we are currently lacking ideas and knowledge about previously described patterns or frameworks.</p>
  
  <p>The tricky thing is, that multiple basically independent WebComponents need to find together for using the ONE central communication path. If the frontend would be realized by implementing one (big) Angular application for example, we would implement and inject a "BackendConnectorService" (Name to be discussed) and inject in to our various components.</p>
  
  <p>But since we would like to use decoupled Web Components, none such background layer for shared business logic and dependency injection exists. Should we write a proprietary JS-library, which will be loaded to the window-context if not present yet from every of our components, and will be used (by convention) to communicate with the backend?</p>
  
  <p>This would roughly integrate to the sketch like below:
  <a href="https://i.stack.imgur.com/otRBA.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/otRBA.png" alt="enter image description here"></a></p>
  
  <p>Are we thinking/designing our application wrong?</p>
  
  <p>I'm thankful for every reasonable idea or hint for a proven pattern/framework.</p>
  
  <p>Also your view on the problem and the architecture might be helpful to circumnavigate the issues we are facing right now.</p>