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!
February 15, 2022, 6:48pm
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:
move over API routes in groups, until you have a Phoenix API + a minimally-changed SPA
incrementally switch SPA parts over to LiveView, until you have a Phoenix + LiveView app
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”:
create a Phoenix + LiveView app that calls the Rails API and migrate the SPA over
incrementally replace API calls with direct writes
February 15, 2022, 7:00pm
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?
Thank you for your insights!
February 25, 2022, 5:17pm
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
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!