Ruby老兵16年心得：网站框架选型与设计铁律

去年12月份，我接手了个电商项目——客户要求3个月上线，日均UV要扛住10万，还得兼容旧版Rails 3.2的数据库结构。这活儿要是搁10年前，我肯定直接甩Ruby on Rails，毕竟它能让开发速度飙到每小时300行代码。但这次我犹豫了——团队里有个新人刚被React的虚拟DOM虐得怀疑人生，另一个老手正跟Webpack的配置文件死磕。

选框架这事儿，我踩过的坑比写的代码行数都多。2008年用Merb（对，就是那个后来被Rails合并的框架）做新闻聚合站，结果发现社区文档少得可怜，遇到个路由冲突问题，在IRC频道蹲了4小时才等到个法国开发者回消息。2015年用Sinatra给某车企做API，代码倒是简洁到能当教材，但当并发量冲到2000时，Puma进程直接被OOM Killer干掉——那晚我盯着监控曲线，活像在看心电图。

现在我的铁律第一条：别被"纯Ruby"绑架——去年有个创业团队非要用Hanami（当时还是0.9版本）重构系统，结果光配置Dry::Validation就花了两周，最后因为缺乏异步任务支持，不得不用Sidekiq+Redis硬补，代码耦合度比原来还高。反观另一个用Rails+StimulusReflex的项目，虽然混了JavaScript，但前端交互延迟从300ms降到80ms，用户留存率涨了15%。

新技术不是洪水猛兽——2022年我试过用Hotwire（Turbo+Stimulus）重构管理后台，原本需要写5个AJAX请求的表单，现在3行HTML+1个Stimulus控制器就搞定。最绝的是部署时发现Nginx配置根本不用改，因为Hotwire的流式更新走的是标准HTTP连接，不像某些SPA框架需要额外配置WebSocket代理。当然，这招在需要SEO的页面不适用——上个月帮某教育平台做落地页，最后还是老老实实用Rails渲染首屏，Hotwire只负责交互部分。

有个失败案例至今让我肉疼：2019年给某金融公司做风控系统，他们CTO坚持要用Padrino（一个"轻量级Rails"框架），理由是"性能比Rails高30%"。结果开发到一半发现，Padrino的ORM（Sequel）和ActiveRecord语法差异太大，团队得重新学查询构建方式；更坑的是，它自带的模板引擎ERB扩展功能有限，最后不得不引入Haml，导致视图层代码混了三种语法。上线后QPS确实比Rails高，但维护成本翻了倍——现在那个系统还在用Rails 5.2重写。

文章配图，仅供参考

下一步我打算研究Ruby 3.2的YJIT对Hanami的加速效果——听说在某些基准测试里，YJIT能让Hanami的响应时间缩短40%。不过这得等Hanami 2.0正式发布再说——现在用beta版跑测试，偶尔还会遇到Dry::Types的类型推断错误，得手动写类型签名，挺烦人的。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!