Hello Elixir Forum! 
I have questions about migrating a client-side specific feature from a React app to Phoenix (or maybe to a traditional server-side app).
I have an existing app built with NextJS and Django (REST) and Iāve been considering to migrate it to Phoenix. But, some aspect of the app might be very well-suited to client-side nature of a React app, and Iām not sure if I can really migrate the whole thing to Phoenix.
Users can submit a product in a multi-step (multi-page) form, where they can upload images (and some other additional files) and edit them in an editor (made with fabric.js) where they can move around/resize the images. Every time it happens, another āpreviewā image is generated on the browser and will be displayed on the other pages in this multi-step form.
Everything happens on client-side: uploaded files and generated preview images are still being kept on the client until users actually hit submit, so the file is not being sent unnecessarily to the server if later on the user decided not to continue the process.
Question: how should I approach to do that on Phoenix?
What I can think of currently is to have the multi-page form, save every step of the form on a ādraftā record and actually āpublishā after the last submit button clicked. I can set up a scheduled job to remove all ādraftā records (unfinished form submissions). But this approach would mean that every files uploaded & preview images generated to be saved on server and sent across the network, with the additional network to/from AWS S3 which Iām using.
Iām new to Elixir and Phoenix and not aware of commonly used libraries/patterns that might fit the problem well, so I need some suggestions would like to just migrate the React component to LiveView + some JS (if thatās possible), or embedding the React component, or rendering React component for this specific route with some other libraries I can found on this forum.
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:
-
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.
-
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.
-
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.
-
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!
