LiveView independent micro-frontend idea: somewhat stuck + repo

Phoenix Forum Chat / Discussions
,
1

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_app acts 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 :blush:

3 Likes
2

You might have a look at LiveState. Full disclosure, I am the author :slight_smile: I think it shares several of your goals (no iframe needed, etc) and has multiple apps in production, some for years.

6 Likes
3

Indeed! I mean to try it out but forgot that it was LiveState! Will try at the next opportunity.

4

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.

4 Likes
5

Thanks for the pointer, Victor!

6

LiveState looks awesome. I have been thinking of using it with react and preact for embedded widgets.

Does LiveState also work with Expo/React Native or Capacitor?

I hope my question is not too off-topic. :sweat_smile:

7

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

1 Like
8

I had not heard of microfrontends before. I suppose an example would be something like the AWS console, where there are a thousand services with their own frontend which are developed independently?

Makes me wonder - what are the limits (on the client) for opening tons of sockets for the different LiveViews? Has anyone actually tried opening, say, 100 LiveViews on one page? Is it a problem?

If so, I wonder if you could multiplex them over one socket or something.

9

Modern ad-riddled websites already open lots of connections at once, although mostly not websockets. There are various patterns of UI composition for microfrontends. I think, indeed, using one connection should be sufficient, thus the experiment.

1 Like
10

With live state using custom elements, I took the approach of allowing an element to provide state to any other element that needed it. There is a community developed spec around this for web components to share context that I leveraged to do this: community-protocols/proposals/context.md at main · webcomponents-cg/community-protocols · GitHub

The nice thing is that it uses events so it doesn’t matter where in the DOM the consumer and provider are, they just discover one another and stuff just works.

1 Like