How Phoenix Kills React

About one and a half years ago we wrote an internal tool for corporate announcements. Initially, it used Phoenix for the backend and React for the frontend. Thus, we got the benefits of Redux and Phoenix channels when delivering updates to the browser in real time.

This allowed us to get a great live interface, but slowed down the development speed and caused a small number of developers involved in the process. About three months ago we decided to throw out React and return to server rendering.

Why we decided to replace React

Real-time update allows you to better immerse yourself in the work with the application, but it also has additional costs.

Development cost

Instead of adding a new feature in one place, we had to deal with it both in the API part and in the UI part. It also meant that every developer who wants to add his own contribution to the project should know both React and Phoenix , which discouraged them from trying to get involved in the work.

Testing

Testing was another sore point when working with the React code. Since the application and the client were separated, it was necessary to be sure that the answers of our test server simulation are always relevant. In practice, this was not a serious problem, but several times it still stuck a stick in the wheels, reducing our confidence in the tests.

Contribute to the project

Finally, we wanted more people to be involved in the work on the project. We found that implementing the functionality in two places is much more labor intensive compared to working in a single place. And trying to coordinate backend and front-end developers is quite tiresome. This is especially important since the work on this application occurs in our “time for development”.

Replacement process

Due to the fact that we already had a ready-to-use API, we were able to rewrite pages on Phoenix and turn on production without affecting the existing front-end on React. Since the application is mostly a CRUD, most of the pages were simply replicated one-to-one, only replacing the className with class and blocks {} with <%= %> .

In places where we needed JavaScript, we went the beaten track of “interspersing” pieces on it. The best example of this approach is a live update of comments. Whenever a comment is created on the backend, we broadcast it to all users. Instead of sending JSON, we create a live-html channel through which we transmit updates in the form of HTML. Here is the JavaScript code straight from the application:

 import socket from './socket' const channel = socket.channel('live-html', {}) channel.join() .receive('ok', function(resp) { console.log('Joined successfully', resp) }) .receive('error', function(resp) { console.log('Unable to join', resp) }) channel.on('new-comment', payload => { $(`[data-announcement-id='${payload.announcement_id}'] .comments-list`) .append(payload.comment_html) }) 

This surprisingly small amount of JavaScript code provides a huge piece of the functionality of our application. Such a strategy for generating HTML on the server and transmitting it to clients is much easier than writing a full-fledged front-end application with the same features.

We also added Turbolinks here, which made the update of the page very smooth and allowed us to get a feeling of SPA.

results

Full migration was relatively painless. We came to the conclusion that in a few months more people joined the project than in the whole year of using the frontend at React. Tests have become much easier to write, at the same time they have become much more reliable. After all, now it’s not necessary that the server test responses are different from the real ones.

Despite the fact that many of the company's employees knew about the ongoing migration, we did not tell anyone that we had poured changes into production. Not a single person mentioned a noticeable difference. Also, no one understood that the application they used was no longer based on React. All thanks to the speed of Phoenix with its significantly shorter page return time and the lack of loading a large piece of data from the frontend application to React.

Lessons learned

At the end of our work, we understood and proved to ourselves that we can write applications on Phoenix with server rendering, which will work just as perfectly as SPA applications on a separate framework. Not only did the finished product turn out to be just as cool, we also began to add new features faster, could be confident in the tests and it was easier to attract developers to participate in the project. In general, I think it was a big victory.

Have you refused any front-end frameworks lately?

Conclusion from the Wuns

Friends! The next article is about creating a blog in Phoenix in a week. Today we decided to discuss another interesting topic related to this framework.

I remind you that we are holding a contest with a cool prize for the victory in which you need to publish a cool article about the Elixir on Habré. And also urge you to actively subscribe to the newsletter . Twice a week we send new articles to the mail, which is not yet publicly available on the site! Thanks to everyone who stays with us!