一个Ruby框架的135天：从个人工具到千名开发者

　　「我只是想要一个比telegram-bot-ruby更快、不阻塞、在Ruby里感觉对的东西。」——Telegem作者的开场白，像极了每个程序员深夜写代码的起点。

　　2025年12月20日：一个不想做框架的人

　　那天他提交了第一行代码。目标很小：解决现有Ruby Telegram库的阻塞问题。telegram-bot-ruby是主流选择，但在异步场景下表现不佳。

　　他没有规划路线图，没有写商业计划书。只是单纯觉得「应该有个更好的方式」。

　　这个起点决定了Telegem的基因——async-first（异步优先），非阻塞，Ruby原生体验。

　　2026年4月：追上Telegram的速度

　　Telegram Bot API更新频繁，多数Ruby封装库落后数月。v3.4.0发布时，Telegem已与Telegram 2026年4月版本完全同步。

　　新增支持包括：托管机器人（managed bots）、多正确答案的投票（polls with multiple correct answers）等特性。

　　作者的原话是：「The works」——全部搞定。

　　Redis存储：从玩具到生产级

　　此前版本会话数据存内存，单进程运行无碍。但webhook模式多worker部署时，共享存储成为刚需。

　　v3.4.0引入Redis存储，解决了这个架构瓶颈。这是一个典型的「从个人项目到被真实使用」的转折点——用户倒逼基础设施升级。

　　135天后的数据

　　Telegem吸引了数千名开发者试用。作者坦言：「不是所有人都找到了它，不是所有人都留了下来。」

　　但这个数字远超他最初的预期。

　　开源项目的冷启动曲线通常陡峭：前100个用户最难。Telegem用四个月跨过了这道坎，说明Ruby社区对现代异步Bot框架存在真实需求。

　　下一步：不做功能堆砌

　　作者明确表态：不会为加功能而加功能。Telegem已进入稳定期，重点转向可维护性和开发者体验。

　　安装方式保持简洁：

　　命令行直接gem install telegem，或在Gemfile指定gem 'telegem', '~> 3.4.0'。

　　为什么这个案例值得看

　　Telegem的路径揭示了工具类开源项目的典型成长逻辑：先解决个人痛点，再被同类开发者发现，最后由真实使用场景驱动架构演进。

　　Redis存储不是作者第一天想做的，是多worker部署的用户需求推出来的。这种「被使用 shaping 产品」的模式，比闭门造车更可持续。

　　对于正在考虑技术选型的Ruby开发者，Telegem提供了一个信号：如果你需要异步、非阻塞、紧跟API更新的Telegram Bot方案，现在有了一个经过生产验证的选项。

　　gem install telegem，试试看它在你项目里「感觉对不对」。