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!
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
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?