这里 https://github.com/ruby-china/homeland/issues

大面积使用 Vue/React 还是适合 SPA，本以为 Rails 后端渲染也没问题的，结果带来了太多不必要的麻烦。

谢谢。Rails 渲染和 SPA 都有自己的合适的场景，不拘泥于框架、找到适合自己的解决方式才是最实际的。

是的，我所遇到的问题是如果想要后端渲染，就不应当过度依赖 Vue。但是有的时候还是略无奈啊，现在很多开箱即用的 UI 库（material、element、ant-design）几乎都是基于 Vue/React/Angular 实现的。既然选择重度依赖前端框架，其实就不该再强行依赖 Rails 在前端方面的传统优势了。

最近做过 webpacker 搭配 vue 的尝试。可以给点简单的建议。先简单比对下后端渲染和前后端分离。

后端渲染 + 前端框架

优点

• 前后端代码都在同一个项目中，方便调试。部署也只用部署一套代码。
• 在 Rails controller 中定义的 variables 可以在 template 中直接使用，省去 JSON API 格式的定义。
• 没有 SEO 和首屏加载的问题

缺点

• 开启了 turbolinks 的情况，需要在 turbolinks 相应的 callback 中销毁和重新注册相关组件。但是如果你使用了基于 Vue/React 这些前端框架的第三方 UI 库，某些第三方组件在 turbolinks 开启的情况下会出现一些意想不到的的问题。

• 表单操作方面，Vue/React 不能直接在 Rails 原生的表单中使用。如果还是使用 ujs 的方式去处理表单，遇到需要 Vue/React 去处理某些数据绑定的操作，也还是不方便。如果使用 Vue/React 去构建 Form，提交表单只能发起异步请求，不会有 Rails 原生表单的行为，一些本来交给 Rails 处理的行为（例如在 controller 中 redirect）需要交给前端处理。而且这样的行为在一个非前后端分离的项目中可能会显得比较怪异。 例：如果使用了 Vue 去提交一个表单，想在提交成功之后做 redirect。由于是一个异步请求，Rails 并不能帮助我们进行 redirect，只能在前端使用window.location这样类似的方式进行 redirect。这个行为既不 Rails 也不 SPA。（SPA 中通常使用 Router 进行跳转）

• 前后端数据命名格式不一致。在 js 中，命名的规范是camelCase，在 Rails 中是下划线的形式。如果你有过 SPA 的开发经验，在写前端逻辑时应该会倾向于camelCase，所以我们还是需要对 Rails 的数据做一道转换。

前后端分离

优点

• 完全使用前端的解决方案，后端只提供 API，具体操作如何、路由怎么跳转完全由前端控制。
• 如果使用第三方 UI 库，不用担心一些由于后端渲染和 turbolinks 导致的问题。

缺点

• SEO。但是这个问题我们需要根据自己的场景去看待。如果做的是一个内容展示型的网站，SEO 十分重要，这时用单页应用就必须通过 SSR 这样的方式去做处理。但是如果我们做的是一个管理系统（CRM/OA 等），大多数的界面都是在用户登录之后才能访问的，也就是说大多数界面我们并不需要 SEO。这时候我们可以将一些公开的界面（如产品介绍页面）做成后端渲染的，登录之后的做成单页应用。SEO 也不再是问题。
• 首屏加载。首屏加载是每一个 SPA 都需要面对的问题。也是 SPA 被诟病的众多原因之一。但是现在的主流前端框架在 build production 之前都会做 uglify 之类的操作减少 js 文件大小，除此之外使用 Lazy Loading、server 上开始 gzip 之后最后得到的资源文件大小并不大。
• Rails 只是一个 API，我们不能使用 Rails 的很多便利的东西（Helper，Form 等）

结论

可能你看到这里会觉得我更加倾向于 SPA。但事实上我所提到的在使用后端渲染 + 前端框架的这些缺点，都是因为在开始项目之前我不希望使用 SPA，所以还是想像使用 jQuery 一样使用 Vue，所以还是采用了后端渲染的方式之后发现的。我在项目中为了能快速搭建 UI，使用了一个 Vue 的第三方组件库，开始时并没有觉得有什么问题，但是随着项目深入之后便发现了我之前提到的这些问题。为了解决这些问题反而花了更多的时间。

但是这并不代表 SPA 就一定是更好的选择。技术选型不能脱离我们的业务和环境。关于究竟是 SPA 还是后端渲染，我想给出我自己的一些建议：

• 如果你有很多重前端的场景，一些业务场景重度依赖于 React/Vue，或者说你使用了一些基于 React/Vue 的 UI 库。为了减少你处理一些不必要的麻烦的时间，建议直接上 SPA。
• 如果你仅仅是用 React/Vue 处理某些交互麻烦的地方，如果 React/Vue 对当前项目来说只是 jQuery 般的存在，后端渲染会是更好的选择。
• 最最重要的是，选择适合当前团队的方案。如果你现在的团队成员有过 SPA 的经验，并且更适应 SPA 的开发方式，那么前后端分离无论是对于开发效率还是质量来说可能都是更好的方式。反之，如果你的团队更熟悉传统的后端渲染的方式，为什么就一定要为了前后端分离而分离呢？前后端分离只是一种不同的开发方式，前后端分离可以实现的业务使用后端渲染一样可以实现。

关于前后端分离的问题，社区里曾有过不少讨论。其实无论是前后端分离还是后端渲染，我们的目的都是为了解决问题，二者没有孰好孰坏之分。你不必因为现在很多项目都选择了前后端分离就一定要去跟这个潮流，放弃后端渲染。同时，也不必像我一样，在场景过于依赖前端框架的时候硬要上后端渲染（这里也有我个人的原因，最近一年的工作很多是和前端相关，对一些单页应用中的业务场景更加熟悉一些）。找到最适合自己和团队的方式，高效高质量地进行开发才是我们的最终目的。

用 Rails 的话，Action Cable http://edgeguides.rubyonrails.org/action_cable_overview.html

赞一下。我最近也在学习 vue，也是拿 ruby china 练的手。发现 vue 中没有比较好用的分页组件（类似于 react-paginate 这样的），楼主 demo 中也是自己做了简单的处理。所以我就自己参考 react-paginate 写了一个简单的 pagination 组件，做了一个 npm 包，还算好用。楼主可以试试。
github: https://github.com/lokyoung/vuejs-paginate

#6 楼 @pengedy 谢谢，其实就是篇 Getting Started 的教程，整理下分享给大家~

#5 楼 @42thcoder 谢谢推荐，之前没有尝试过 gitlab，准备深入了解下！

#3 楼 @ACzero 我们正好有项目有这样的需求，我最近就弄了下

#1 楼 @shawzt 嗯啊谢谢建议，确实如此，下一步可以做一个 Jenkins for Rails 的 Docker Image 。

#14 楼 @i5ting 嗯，后来看了下是通过 shell 装的。不过也提供了 npm 的方法就是了。

Getting Started 第一行

$ npm install -g yarn

Ruby on Rails tutorial http://railstutorial-china.org/

这个是两次请求。你看每次 request 的最后一行 Complete OK in ..ms。第一次是 84ms，第二次 70ms。

#18 楼 @u1450154824 很久以前写的，很多代码和配置都不能用了。最近抽个时间更新下。谢谢提醒。

#42 楼 @tq0fqeu 可以用 Upstart/Systemd 这种系统自带的方式，从进程本身角度解决监控和崩溃重启这些事。相比之下，god 就是不必要的依赖了。

#39 楼 @vkill kill you dependency....此外现在投入生产环境的 Linux 服务器有很大一部分还不支持 Systemd，所以对现有服务器来说 Upstart 还是一种很好的解决方式。当然，Systemd 是趋势这毋庸置疑。

#37 楼 @unbug 至少对于 Sidekiq 来说，Upstart 算是最佳实践了。

#35 楼 @lgn21st 赞！

#30 楼 @zoker 用 Upstart 吧，用脚本去检测感觉并不是种好的方式。

#31 楼 @cod7ce 谢谢指正！

#26 楼 @huobazi 当时 supervisor 也是备选之一，由于后来使用了 Upstart 就没有去仔细了解了。不过 supervisor 应该仅仅是监控进程并且也需要安装相应的包。而 Upstart 是系统自带的，我们系统中的 Sidekiq 进程直接通过 Upstart 启动，进程本身也算是一个 Upstart 进程，这样解决我觉得更加彻底并且没有依赖。

#25 楼 @lgn21st 那看来是要与时俱进了。 啊哈，其实写出来也是让我自己把这些知识巩固下。看到这么多人支持，真心感觉到社区的好！

#17 楼 @lgn21st 其实当初碰到这个问题不知道怎么解决，还是在社区里搜索 sidekiq 相关问题，然后发现你在一个回答中推荐使用 Upstart/Systemd 并且给出了 Sidekiq 作者的那篇文章，我才去了解然后发现这对我而言几乎是最好的解决方案了。所以感谢！

#19 楼 @liwei78 也谢谢你的支持！看到对大家有帮助，我也非常非常开心！我还是一个新手，如果有哪里疏漏的，也欢迎并且谢谢指正！

#15 楼 @mingyuan0715 Thank you very much!

#17 楼 @lgn21st 谢谢建议！对于最新 Ubuntu 系统（16.04）的确要不适用了，本文的适用群体应当是 Ubuntu 16.04 之前的系统。是的，Systemd 会是趋势，配置也更加方便。不过现在大部分服务器使用的是旧版本的系统，而服务器系统升级需要很大的成本，所以可能在很长一段时间里，旧版本系统的占有率还是会很高吧~

#9 楼 @xiaoronglv 谢谢，得到认可很开心，个人感觉 Upstart 和 Inspeqtor（二者都不仅仅局限于 Sidekiq）还是挺实用的~