Migrating React app to Phoenix

depdepdep

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.

5 comments

/phoenix #react #liveview #suggestions

0 2305 5

2021-05-16 06:29:05 UTC

Showing Posts 1 to 5

Show Best Posts
Show All (oldest first)
Show All (newest first)

BartOtten

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

Post #1

kokolegorille

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.

Post #2

thomas.fortes

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).

Post #3

depdepdep

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!

Post #4

depdepdep

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!

Post #5

— All posts loaded —