d-led
LiveView independent micro-frontend idea: somewhat stuck + repo
Hi,
For some reason the idea that micro-frontends could profit from the optimizations of Phoenix LiveView does not leave me in peace.
If anyone has been thinking about it, and would like to experiment, or point to an existing blog/talk/repo, that’d be great.
I have a repo with an experiment, and am stuck due to lack of time,
but it has a minimal functionality to play around with already.
Constraints:
-
no iframes
-
no dependence on OTP app update mechanisms
The imagined architecture:
-
Separate, independent teams can build and operate both LiveView UIs with maximum simplicity and deployment flexibility
-
The front-end degrades gracefully if micro-front-ends are down
-
Optimizations of LiveView can be utilized, trading for some chattiness between the services
Currently:
-
3 independent nodes are connected in a cluster
-
the
main_appacts as the front-end, serving the main page -
2 services push rendered partial LiveViews to which the main_app is subscribed, rendering them as they are, within the main view
I naively tried sending the diffs only but failed, presumably, since the services are independent and using the diff
optimizations would require calling functions, available in each separate app only.
I’m sure it can be done better ![]()
Most Liked
superchris
victor23k
Hey Dmitry, you might want to take a look at this: support multiple livesockets by gfrancischelli · Pull Request #3564 · phoenixframework/phoenix_live_view · GitHub
Related to that, I’m working on a way to take this a step further and use LiveView for embedded widgets. The difference in that approach is that the owner of the main page would be a third party. Maybe there is some overlap and it could solve both problems. You can take a look at the proposal here.
superchris
The client js lib is a very thin wrapper around the phoenix channels js client. It definitely works fine for react, I wrote a react hook in <30 lines. It should work anywhere I would think







