How to fit Phoenix LiveView into micro frontends architecture?

Hello. I have micro service architecture where each service is owned by separate development team. Each micro service could be represented as separate page on product website with common for all pages header and footer. Instead of heaving one monolithic FE I want each micro service to serve its own Phoenix LiveView frontend combined in one website using micro frontends (https://micro-frontends.org/) approach.
I have next primary questions:

  1. What is the best approach to combine LiveViews served by different services on one website with common elements (like header an footer) between all pages?
  2. How to handle authentication and authorization in such case?

Hello and welcome,

If You mean micro frontend build with web components, I don’t see any problem integrating them with Liveview.

You might have to use phx-update=“ignore”, but I am not even sure.

Sharing elements is done in the root and live layouts. Simply put them there and they should appear on each live pages.

Authentication and Authorizazion might be delegated to a normal controller, storing some user data in the session, which is then passed to Liveview.

Hello.
Thanks for your reply!
Regarding authentication and authorization - you propose to share the same plug session between different phoenix applications (e.g. micro services). Does it mean that I need to share the same secret_key_base endpoint config? I also use Guardian, so I suppose that guardian secret_key also should be shared among services.
Is there any alternative approach to handle authentication and authorization without sharing the same session between different services?

I was more describing a single Phoenix instance, with multiple frontend teams working on web components…

Ok, so what about several phoenix micro services, each serving own html. Could you give any guidance for such case?

Unfortunately I cannot help You as I have never tried to split into multiple Phoenix instance. For the very reason You are mentionning… lack of shared session, auth difficulties etc.

2 Likes

Thank you. Will try to overcome this issues. I think splitting LiveView FE across multiple phoenix application provides great benefit for big system because all service related code locates in one git repo, could be deployed and updated independently from other parts and gives an ability to deliver full fledged part of product by one team without interfering others.

Hello,

You do this in the same way as you do it in other tech. I already see this in a c# company. Basically they add iframe (or load a page inside a div with JavaScript).

For authentication you can use Oauth for example.

For that kind of architecture I prefer use a front tech (react, VueJS…) and have backend working as simple API. Then you can use phoenix channels that allow you to do a lot of things easily.

However dealing with « big » project is really nice in elixir (thanks to umbrella). You can setup multiple git repositories for each app and another one for the project. Then you add all your apps to the project thanks to git submodule.

For the deployment there is lib like horde that can help you to save the state of your apps. Using it with k8s allow you to deploy without loosing state and/or downtime of your apps.

But splitting a project into multiple apps is good. Just want to give you all keys to make the best choice.

Hope it help

In my team, we have 6 Elixir+PhoenixLiveView microservices, each with their own frontend. We share the SECRET_KEY_BASE, and Cookie options as defined in endpoint.ex among all of them. This way, we can authenticate a user through the Cookie on every microservice.

We share the CSS and JS dependencies among all FE so that our styling is always consistent. We configured the routing using CloudFront (I wrote about the setup here) so that every microservice can serve their own endpoint and we don’t have to use iframes and such.

I hope this helps :slight_smile:

6 Likes