文档结构  
翻译进度:50%     翻译赏金:0 元 (?)    ¥ 我要打赏

在一年半前,我们开发了一个在公司内部使用的公告板程序。我们使用了Phoenix作为后端,React作为前端。利用Redux和 Phoenix channels 的优势,我们得以实时的发送消息给用户的浏览器。

这个方法可以很好的提高实时的体验,可是随之而来的,却是降低了我们开发的步伐,而且导致更少的人能参与其中开发。在大约3个月前,我们决定放弃React,转而回到服务器端的渲染。

 

我们为什么决定放弃React

当用户使用浏览器与应用交互的时候,实时更新可以提升用户的使用体验。但是这个好处是需要有额外的代价:

第 1 段(可获 2 积分)

开发成本

相对于在同一处地方构建新的功能,使用这种方法,我们需要同时在API和UI上开发程序。这也就意味着,如果任何一个开发者需要加入其中,就必须得同时了解React和Phonex,这就大大降低了开发者参与其中的意愿。

测试

另外一个使用React的痛点就是测试。因为服务器应用和React客户端的分离,意味着我们需要保证测试服务器需要实时同步。在实际操作中,这并非是个很大的问题,但是却需要占用我们的时间,而且降低我们对测试结果的可信程度。

第 2 段(可获 2 积分)

参与贡献其中

最后,我们需要更多的开发者参与其中。我们发现,在前后端分别开发一个功能,相对于在同一个地方(后端)需要花费更大的精力,而且我们需要配合前后端的开发,这可是个让人觉得烦闷的事情。尤其是,我们离交付的时间越来越近的时候。

替代方案

因为我们已经有一个API方案,所以我们可以通过Phoenix重写页面,并发布到生产环境,而不需要影响到现有的React前端程序。另外由于,app大部分是做CURD操作,所以大部分的页面可以快速的通过一对一的复制到HTML,并使用class替换原来的className, 同时使用<%=%>替换{}。

第 3 段(可获 2 积分)

In the places we needed JavaScript, we took the tried-and-true path of “sprinkling” on the JavaScript. The best example of this is live-updating comments. Whenever a comment is created on the back-end we broadcast to all users that the comment was created. Instead of sending JSON, we created a live-html channel where we broadcast HTML updates to users. Here’s 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)
})
第 4 段(可获 2 积分)

That’s a surprisingly small amount of JavaScript that powers a huge piece of functionality in our application. This strategy of generating some HTML on the server and broadcasting it to clients is much simpler than writing your entire front-end in JavaScript for the same functionality.

We also added Turbolinks to the app which makes page transitions nearly seamless and let us keep that single-page app feel.

The results

Overall the migration was relatively painless. We ended up having more people contribute to the project in a few months than we previously had in a year with the React front-end. The tests are much easier to write while also being much more reliable since we didn’t have to rely on the payload the back-end sends matching up with the payload we used in tests.

第 5 段(可获 2 积分)

Although a lot of people in the company knew the migration was happening we didn’t tell anyone when we pushed it to production. Not a single person mentioned seeing a difference or knew that the application they were using was no longer powered by React. This was because the time to load pages was greatly reduced thanks to Phoenix’s speed and not having to bootstrap a large amount of data on the front-end via React.

Lessons learned

In the end we realized and proved to ourselves that we can write Phoenix server-rendered applications that are just as great as front-end framework-powered single page applications. Not only is the end product just as great — we can write features faster, have more confidence in our tests, and more easily have other developers contribute to the application. Altogether I think this was a huge win.

What projects have you removed front-end frameworks from recently?

第 6 段(可获 2 积分)

文章评论