3

we are currently facing some tough architectural questions about integrating multiple Web Components with individual backend services in a composite web UI to one smooth web application.

There are some constraints an (negotiable) design decisions:

  1. 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
  2. A frontend WebComponent needs to be able to recieve live updates/events from it's backend MicroService
  3. The page (sum of Web Components used in the composite UI) shall only use one connection/permanent occupied port to communicate with the backend

I made a sketch representing our abstract / non-technical requirements for further discussion: enter image description here

As of my understanding, the problem could be rephrased to: How do we

a) concentrate communication on entering

b) distribute communication on exiting

the single transport path on both ends.

This two tasks need to be solved on both sides of the transport path, eg. the backend and the frontend.

For the backend, I am quite hopefull that adopting the BFF pattern as not only described by Sam Newman could serve our needs. The right half (backend) side of the above sketch could then look similar to this: enter image description here

The transport path might be best served using standardized web technologies, eg. https and websocket (wss) 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.

For the frontend we are currently lacking ideas and knowledge about previously described patterns or frameworks.

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.

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?

This would roughly integrate to the sketch like below: enter image description here

Are we thinking/designing our application wrong?

I'm thankful for every reasonable idea or hint for a proven pattern/framework.

Also your view on the problem and the architecture might be helpful to circumnavigate the issues we are facing right now.

Saphirim
  • 55
  • 9
  • Have you ever read the eShopOnContainers from Microsoft? It seams to me that is what are you aiming for, since you are a .net developer. – Matheus Valiente Souza Oct 16 '18 at 10:56
  • @MatheusValienteSouza Yes I've previously looked at this demo, but it's using one SPA for the frontend and therefore not facing the problems we especially have there. – Saphirim Oct 16 '18 at 11:05
  • It seams that it is a implementation of BFF pattern, because the eShopOnContainers also handles different frontend devices, take look [here](https://user-images.githubusercontent.com/1712635/38758862-d4b42498-3f27-11e8-8dad-db60b0fa05d3.png). – Matheus Valiente Souza Oct 16 '18 at 11:13
  • @MatheusValienteSouza As mentioned in my question, I am empathizing the BFF pattern for the backend side of things. But what is giving us the headache is a proper strategy to concentrate/distribute traffic in the frontend from/between decoupled Web Components instead of using a (monolithic) SPA. – Saphirim Oct 16 '18 at 11:52
  • As far as I understand it, using web components is quite limited in its capabilities, as it can only load HTML snippets, and some simple JS to go with it, as it is not a full page load, I don't think you can load a whole js bundle into it (happy to be corrected on this one). Iframes are a possible solution, but they come with their own issues - if you want full interactivity between your decoupled components, it won't be 100% - you need to consider your use cases to make sure that things can work as expected around browser history and the back button – Mikkel Nov 02 '18 at 05:13

1 Answers1

0

I would go with same approach you are using on the backend for the frontend. Create an HTTP or WS gateway, that frontend components will poll with requests. It will connect to backend BFF and there you solved all your problems. Anytime you want to swap your components, transfer or architecture, one is not dependent on the other.

Tree
  • 29,135
  • 24
  • 78
  • 98
  • But how would you make your frontend components share a single WebSocket connection? – Saphirim Oct 17 '18 at 08:56
  • You need to have one connection to frontend gateway, and another to backend gateway. So the solution is use redis messenger for communication between frontend components, and one component is gateway for backend that uses ws – Tree Oct 17 '18 at 11:26
  • You could use a Web Worker or a Service Worker – Supersharp Oct 17 '18 at 21:03
  • @Supersharp can you provide more details about using webworkers? – Mikkel Nov 02 '18 at 05:09
  • @Mikkel you could take a look at Jack Archibald introduction or other resources at the end of this page:https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers, or in the MDN documentation: https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers – Supersharp Nov 02 '18 at 13:31