Best workflow between JS Frontend w/ Elixir backend as a solo-dev?

I’m going through a similar situation at the moment. I’d already evaluated a few of the options discussed in this thread and came to a conclusion - it depends

You haven’t described the problem space that your product is trying to solve. For my project, it involved a lot of use of the Twilio API. I started with LiveView and used React for the Twilio bits of the page. When I pushed LiveView hooks to their limit, I ported the whole page over to a React component rendered using Remount in a standard heex template. The React HOC that manages everything is getting pretty gnarly, so further down the line I might move most of that out to a SvelteKit app.

I’d say start with LiveView, as your pace of productivity will be much faster than all the extra work required by you trying to keep an API and SPA always working together, especially if you’re duplicating business logic on both sides. If/when you bring someone else on board, then you re-evaluate, or they might be fine with learning Phoenix.

Everyone in this thread raises some good points, but I think @thojanssens1 and @AstonJ are on the money.

IMO, if your idea is design heavy or requires a lot of client side interaction that LV isn’t suited for, then build it using whatever JS framework you like. If not, start with LiveView and push it as far as you can.

3 Likes

Hey guys, thank you very much for all of your responses. I’ve decided to do my best to accomplish things in Live View. I have attempted learning this side multiple times but I’ve read much more and am willing to try again.

I think once I get it down I think @dewetblomerus is right that I will be able to iterate and build faster.

Thanks to everyone for their responses. I’ve read all of them and each one made me think about how I will proceed.

5 Likes

Sounds wise!

I used a lot of front-end technologies before: PHP, Java, a lot of Rails, Phoenix + React, and I never felt so productive as with LiveView.

I think the learning curve can be a bit steep, but totally worth it!

Start with raw LiveView and then start learning PETAL stack. You’ll eventually find yourself even more productive if you leverage on components.

Good luck :muscle:

4 Likes

I wanted to use LiveView but after experimenting a bit I’m not sure it’s the best fit due to the latency aspect. I used JS commands and hooks to overcome some of that latency but hooks in their current form don’t feel great. It would feel much better with colocated hooks, which I think are on the roadmap, but even then it feels a bit like I’m fighting against LiveView if I want things like optimistic UI.

So now I’m experimenting with a SvelteKit SPA on the frontend and Phoenix Channels for the backend. My proof of concept seems to work nicely with the default setup for each. I’m not sure what the best approach is to deploying this setup though. It seems like it’d be easier to deploy it as one app rather than deploying the backend and frontend separately but maybe I’m wrong. If anyone reading has any tips, I’d appreciate it.

2 Likes

Build your JS project as artifacts and serve it with phoenix static plug? I never got to doing that in practice, however it should be much more manageable compared to having backend/frontend as separated instances.

You can do both…

If You choose to host in the same project You won’t need to worry about CORS, but it is less flexible, because frontend and backend do not evolve at the same pace, but they are linked in the same repo. You don’t need a dev-server, because Phoenix will host the frontend

If You choos to separate the frontend, You’ll have to setup CORS and websocket cross origin

As I like to test different frontend solutions, I prefer to separate backend and frontend. That would work too if You have separate teams

1 Like

Hi Morzaram. Would you be able to share what have you chosen at the end and how was the development experience? Would you do anything different? Was it easy to bring in and collaborate with other developers? Thanks in advance

1 Like