看业务，看团队的体量。如果业务和团队是从小开始做大，这样可以逐步拆分业务。微服务是个好东西，但要看是否适合，如果带来的结果是维护成本大导致开发效率影响业务发展，这就得不偿失了。

Awesome job! 荣幸文章能被收录，一直觉得Ruby-China是技术讨论氛围最好的中文技术社区！

喜欢楼主很久了，投份简历试试

还有一个名额

@ruomu 可以的，我们同时也在招聘NodeJS的职位，我们主要看的是自学能力和态度，当前能力和经验都可以提高的。当然也希望在考虑应聘前，要对Ruby/ Rails和web开发的基础都有个熟悉。请投简历

炮哥帮忙推荐下！

这是一个例子，注意目录结构，外部的calendar.js里的这句话，会引用calendar/目录下index.js文件

@huacnlee 反向查询count时，如果之前没有请求一下Origin Object， 会导致Target Object xxx_by_users method undefined, 例如:

#User Model
action_store :star, :article, counter_cache: true, user_counter_cache: true

#但是在测试里
@article = create(:article)
@article.star_by_users  #method missing error
User #随便读一下user class
@article.star_by_users # => []

觉得CtrlP已经够用了，代码片段一边用ack-grep

真要对比出来，可能要新开篇去说了。只能说下对于小公司来说，webpacker有点给我们带来这些好处: （1）以前前端同学写完后推代码，等运维同学拉代码部署到运行容器，接上数据查看有没出错，出错了还要重来一遍。现在直接本地可以同步效果，在同一个环境下不会再存在一些额外需要去把API服务器调跨域之类的问题。 (2) precompile后的工作和assets pipeline差不多，原来的部署脚本也一步到位了 (3) 像基本我们百分百对外项目静态文件都用到CDN的，用手动分离的方式中间要做很多的整合工作。 (4)和assets pipeline对比的优点就更不用说啦，yarn 对比gem，babel es6 es7 特性对比coffee，webpacker自带处理的各种vue-loader啊，portcss之类的，assets pipeline都会很别扭。

综合地来说，就是对前端用得比较深的，都知道现在webpacker是大一统，前端最前沿的技术都在这里可以体验。assets pipeline和turbolinks是能顶大部分的需求，还是看项目情况使用吧。