bartblast
Suppose you’ve got a Rails app used as the backend, which provides REST API for an SPA frontend such as React, Angular or Ember.
What’s the best approach in your opinion to migrate it incrementally step by step to Phoenix LiveView? The requirement is that it’s transparent for the end user, so no big rewrite.
I’m thinking about using a kind of a reverse proxy which would route already migrated routes to Phoenix LiveView and the non-migrated routes to SPA.
How to handle authentication?..
I’m aware of such packages as PlugRailsCookieSessionStore plug, rails-reverse-proxy gem and reverse_proxy_plug. Are they applicable in this scenario?
Did anyone migrate to Phoenix LiveView incrementally from a similar setup? What was your procedure? What problems have you encountered? Thanks!
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Catch errors, track performance, monitor hosts and more.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Bringing learning, work and compliance together since 1987.
Producing high quality Elixir screencasts since 2017.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 4- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
al2o3cr
Client-side routing in the SPA seems like it would significantly complicate this - you’d need to change the SPA to send a request to the server for some routes.
What’s the reason for rewriting to LiveView? That may inform the migration strategy, if there’s a way to start delivering visible results towards that goal incrementally.
You may also find it less painful to migrate in two steps:
This is a “backend first” approach where the SPA changes as little as possible while the Rails part is being replaced.
Flipping things on their heads, there’s a “frontend first” approach but it seems trickier because “make the UI identical” is harder than “make the API identical”:
03juan
What about replacing a part of the SPA by manually mounting a liveview websocket that mutates that part of the DOM independently, and then progressively move more parts of the SPA until the entire route can be rendered through the Phoenix endpoint?
bartblast
Thank you for your insights! @al2o3cr @03juan
mrkurt
I’d do it route by route and let Phoenix proxy the old stuff.
We run a Phoenix app in front of a Rails app (and a few others, actually), and use this Plug to route pretty much everything to our origin app: GitHub - tallarium/reverse_proxy_plug: 🔛 an Elixir reverse proxy Plug with HTTP/2, chunked transfer and path proxying support · GitHub
When we decide to take over a path, we just add it to our Phoenix router.
We also have Ecto types for a bunch of database stuff the Rails Migrations manage. It works well!