Rails with SPA to Phoenix LiveView migration

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!

1 Like

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. :thinking:

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
2 Likes

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?

1 Like

Thank you for your insights! @al2o3cr @03juan

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!

3 Likes