I’ll caveat that I’m very new to Elixir and Phoenix so take my answer with that in mind. However I’ve been coding in React/Node for many years.
Without knowing the exact requirements of your app, this sounds to me like unnecessary overhead just to get some pages statically generated. Why not start with just Phoenix across all your routes and look to optimise with static generation later if you have heavy traffic?
It sounds like you’d be trading all the ease of development that Phoenix offers to benefit some of your pages load times / server usage but you’d be adding layers of complexity and possibly latency everywhere else.

It sounds like you’re not sold on LV, which is completely understandable, but why not use React for your FE with a Phoenix API+channels, which is not an uncommon setup (this is my stack at work for the last 3 years)? I don’t see the reason for introducing a third layer just for a CRUD API? Phoenix can serve static pages just fine as well…

I’m in the same boat! And I ultimately agree with your advice. It’s definitely unnecessary overhead, but I also think this is a pattern that could be quite common, especially for people that want to dabble in Phoenix, without being 100% sold on LiveView or are building applications outside of just a web app.

That said, I am doing this as a learning experience/experiment so I’m alright with the overhead for now. I found a few things that touched on what I was going for since posting this.

I’m not all in on Next.js /the JavaScript framework itself. I actually wanted to give Remix a fair shot, and reading through this doc gave me some ideas on how I might be able to approach the separation of server-client state: Backend For Frontend | Remix. Also, I found this repo on another thread that I might borrow some ideas from: GitHub - arcanemachine/phoenix-todo-list: Yet another todo list. Made using the Phoenix web framework. Features: Basic CRUD, LiveView CRUD, REST API, OpenAPI spec, Playwright E2E tests, GitHub Actions CI, and more! · GitHub.

There are many downsides to doing what I’m suggesting if I plan on simply creating a website. This approach would mean that for any pages that hit the Node server first, I am mostly likely going to be doing unnecessary network hops. Client → Node server → Elixir → DB → Node → Client. However, for Phoenix channels, I am going to talk directly to my Elixir service and not overcomplicate that.

In addition, Auth and any communication to third party services will also happen in my Phoenix application. So really my Remix setup will be making redundant calls and ultimately provide no other value than an opinionated framework for writing JS/React.

The biggest hurdle so far for me has actually been finding an out-of-the-box auth solution. phx.gen.auth requires HTML (at least for the code generation) and while I have been trying to repurpose that for an API architecture, it is quite challenging for a newbie.

Either way, I’m going to continue with this approach, maybe it will make sense to use the SPA mode that Remix just introduced, but either way I’m not quite ready to give up on JS… Probably controversial, but the Phoenix development experience compared to the React toolkit isn’t there yet and I’m not ready to give it up.