Welcome! But…but…why? What advantages do you expect Phoenix (Live)Views will bring you in this use case? If we know, this might influence the advice.

Option 1: less Python
Phoenix can act as API server. You could swap Django with Phoenix + Absinthe (and use it’s websocket subscriptions). Then you can keep the React frontend.

Option 2: less javascript
Try Liveview; but know how to combine it with Javascript libs before you start building and keep in mind the roundtrip delays.

Option x, y, z…etc we need more info

It’s doable without any problem… Phoenix uses webpack under the hood, which goes well with React.

What You will gain is Phoenix channels, think of it as socket.io. Or a bidirectional canal.

Phoenix shines as backend, and You will find many tools to build REST Api, or GraphQL Api.

But the trend with Phoenix is LiveView, a sort of React server side.

You might get a glimpse of what it is here…

Learning Phoenix should not hide You are using the BEAM. It is a virtual machine specialized for concurency and fiabillity. It was hosted (the BEAM) by major telecom system.

Hi @depdepdep and welcome, I would say the same as @BartOtten, why?

Right now I’m experimenting on a side project using wasm to resize on the client a bunch of images before uploading them to the server, the reasoning is that I want to offload the image processing to the clients so I can run servers with a bunch of load balanced low resource VMs before uploading them straight to an S3 compatible bucket (even though the standard liveview upload is not intended to do it, so far it seems viable).

I don’t see anything that would be a blocker to phoenix in your post, in my experience you would have to write a good amount of js to handle the client processing but it still is perfectly viable, mixing liveview code and js processing is easier than it seems, but be advised that there aren’t docs for all the use cases that you will find in bigger communities and maybe you’ll have to figure out things here and there (but the forum is always responsive and can help you if you find a blocker).

Hello, thanks for the welcome and replies @BartOtten @thomas.fortes !

Totally sorry, I should have mentioned that by migrating to Phoenix I meant to use Phoenix as a “MVC” and use views, not an API server.

The reasons of why I wanted to migrate the existing app from NextJS/Django REST to Phoenix are:

1. LiveView on other parts on the app.
   The app has a dashboard with all the product sales for a user and product pages that would hugely benefit from real-time updates with LiveView.

2. Learning
   I’m attracted to the actor model concurrency, supervision trees, capability to open tons of processes, and while the app might not need such advanced capabilities, by entering Elixir/Phoenix and learning now I hope I can familiarize myself and eventually use those capabilities when I need. I enjoy FP-styled coding at Java & TS so why not give Elixir a shot, since Phoenix is well-known and widely used already.

3. Simplifying
   The current NextJS “client” and Django REST “server” setup is good (I can get SSR benefits from Next) but its more cumbersome to maintain and operate with for a one-team dev like me. By keeping things server-sided (“MVC” approach instead of “API server & JS-based client app”) I can maintain only one thing (dev and deployment). Other benefit is to reduce duplication in payload typing on client/server and eliminate additional code for the client-server model (fetching/submitting data, state management, auth, etc). It’s much easier to do authentication too.

4. Template
   Because templating is fast (precompiled) on Phoenix, I don’t have to worry about it and can move from NextJS which I initially used because of the pre-rendered pages (and the client-heavy feature that makes me resort to React on the main post)

I know for reason no. 3 I can go with any server-side/“MVC” frameworks (aka Django since I’m already using it) but for the other reasons and because templating is fast (precompiled) on Phoenix, I dont have to worry about it.

Hope that helps to clear out some backstory for my question!

@thomas.fortes
Your usecase seems pretty similar to mine, processing images on the client, and that same reason is exactly why I did it with React (because of client-heavy functionality and my familiarity with React).

I will look into translating the React components for the image processing parts to plain JS (+LiveView perhaps), or to visit some of the “React component embedding” libraries I listed on the main post. Might want to explore the React component embedding libraries first since it would take less time and perhaps easier, but please give me some suggestions if someone has a similar case before!

Hello @kokolegorille , thanks for the reply!

The main reason I want to enter Phoenix is to move out from the “client and API server” model with NextJS/Django REST that I currently have, and also to use LiveView on other parts on my app. (and some other reason I described on my previous post)

I will take a look on possibly embedding the React component for some routes and if there’s any Webpack setup I might need to have.

Thanks for the LiveView upload resource, will take a look on it!