Rem Kim - 2021-02-20

Migrate from Rails to React two simple approaches

Migration from legacy Rails app to React can be a challenge, I have helped 2 companies to perform a migration and would like to share 2 different approaches those companies used.

Legacy Rails app

There are many legacy applications out there that want to migrate to new modern web apps using React or Angular, to bring much smoother and better user experience. However with existing client base and huge number of features to re-implement it becomes a huge challenge.

In my experience I had 2 cases of Rails to React migration and both took different strategies.

• React app within Rails using webpacker (React in Rails)
• Rails app with React app on a separate domain as an iframe (React iFrame)

Both approaches are viable and as practice shows work well in production.

React in Rails

Probably will be first pick for many teams when deciding on how to migrate to React. Latest versions of Rails already come with Webpacker, however if you are running earlier version of Rails you will need to manually setup it up.

In general this approach is easier. You will still be working in existing Rails app. You can pass Rails props to component hence opening up room for server side rendering. On the other hand if you had a plan to completely detach Frontend from Backend, this does not really help since both Frontend and Backend codebases are in single monorepo, but if your team didn't have such plans and you just want to have React on Frontend then this will work well for you.

Pros:

• Easy to start, lots of documentation on Webpacker and React
• Add components to Rails pages
• Potential to SSR (Server Side Rendering) if needed
• No headache maintaining separate build/deploy pipeline

Cons:

• Rails monolith is getting even bigger with 2 codebases in single repository
• Issues with running Webpacker for earlier versions of Rails
• Build time is longer

React iFrame

Not as an obvious choice for some teams, however has its own pros and cons.

This approach helps to separate Frontend from Backend. You will have another repository for React app, which means it needs to have its own build and deploy pipeline. It can be a headache now that for full end to end feature you will need to coordinate backend and frontend deployments to make sure everything is delivered at the same time. But once migration is complete you will get a complete frontend backend delineation, now dedicated backend team can work on API and frontend team on React app.

Iframe has its limitations and they can be a deciding factor when picking this approach.

If you want to use react-router then you will find that even though you can navigate within iframe it will not update parent URL.

If you have authenticated pages, assuming you pass a token to iframe, React app will have to refetch user on every page when navigating in Rails app between React pages.

Pros:

• Offload Frontend pieces from Rails monolith
• Separate build/deploy pipeline
• After migration is complete Rails becomes API only server

Cons:

• Build/Deploy/CORS headache
• No control over URL in iFrame
• Need to authenticate on every page

Conclusion

Like I said before both of those approaches work and depending on what you try to achieve one might work better than another. It is a common thing for legacy apps try to migrate to modern web frameworks, so knowing those techniques and their pros and cons can come in handy!