Ruby 新写的 Web API 框架今天升级了一波
之前就这个框架发过一遍帖子。近期由于新冠疫情，公司业务停摆了，全员停工放假，故而集中精力将先前的框架整理了一波。框架地址：
现在框架的适用性和稳定性比我第一次发帖时有了大大的提升，已经在我的一个个人项目应用上去（openapi.yet.run），并正在应用在我公司的一个新项目上。希望感兴趣的朋友可以试用之，并提出改进意见。
框架有了名字
框架有了自己的名字：meta-api. 有关取名的思路，可阅读：名称由来。
如何试用
我为此提供了一个脚手架：
这个脚手架没有使用到 Rails 全家桶，而是将 Rails 能用到 ActiveRecord 组件单独抽出来了。如果你想要用的是别的框架如 Sinatra、Grape 等，同时也不想引入 Rails 路由那一套，也可以参考这个脚手架的思路改造。
支持
由于框架尚未成熟，可能会遇到各种问题，我特地建个 QQ 群在线实时答疑。（QQ：489579810）
最后的心声
目前框架已经初步达到可生产应用的程度，但实际效果和稳定性还需更多的项目测试才行。我的个人项目上在运行，公司的项目仍在开发中。最近由于奥密克戎的折磨苦不堪言，对人生更少了点期待，也更愿意沉下心来做点自己的事情。
希望 未来更好，且行且珍惜吧！
加油
amonlei
回复
这区别挺大的，毕竟是两个框架了。Rails API 模式仍然是基于 Rails 的，它仍是属于 MVC 模式的框架，譬如定义路由，编写控制器，以及要用 JBuilder 去渲染视图。Meta 框架就不属于这种 MVC 模式了，它天生地只适用于 API Only，不能做全栈框架。Meta 框架是用声明式的语法编写 API，比如声明它的参数模式是，它的返回值模式是等等。同时，它天生地就与 API 文档结合，在编写声明式 API 时自动生成文档，不用再写两遍。
如果开源的话，建议
- 单独的组织，存放相关的源代码
- 清晰的授权协议，LGPL-2.1（没想到不是 MIT 的原因）
- 示例
- 文档
- PK（优势，和 Rails 比较，牛在哪里，吸引人）
awking
回复
谢谢你的建议，这是按照标准开源项目的模式去展开的思路。
不过真在实施时会有很多问题。因为后发劣势和个人开发，我的项目发展有很大的不确定性，大概率是达不成多大的流行度的，何况我做的是框架这种偏基础的构建，竞品太多了。说实话，我只是按照这个理念作个人感兴趣的东西，也就是我不喜欢 Rails 的地方，改造为我喜欢的方式去开发。所以，当前的情况还是个人开发的阶段，还没达到形成一个组织开源的程度。
我个人是非常在意文档的，所以文档我是提供了的：教程。其中也是有示例。如果觉得上手不够方便，我也提供了一个脚手架，开箱即用，方便学习和调试。
至于开源协议，我还并没有深究，毕竟自己用 LGPL 和 Apache 惯了。至于不用 MIT，我发现大部分项目好像是用的这个，比如 Rails. 我不确定一定要用它的理由，不过既然存在就是合理的吧。LGPL-2.1 是这样的，如果你只是引入这个库，那你的项目是不用开源的；但如果你要修改这个库（二次开发），你就一定要开源，回馈给社区。我感到奇怪的就是，像这种基础框架的部份，闭源的意义何在？所以，如果有绝对的理由，我可能会换成别的开源协议。
最后和 Rails 的比较，我在三楼里也提了一嘴，希望能够说明一些情况。我一开始没想到与这种那种框架作比较，只是提供一个新的理念和思路，供同样感兴趣和有同样需求的人去选择。如果真要走这一步，要“踩”在 Rails 的脚上才能有发展的机会，我未来可能会花一定的精力去写相关的比较文档。
最后，我总结下：目前我的项目仍然是小众项目，还在寻求“共鸣”的阶段。我自己提出了个理念，然后做了个尝试，证明一下它的可行性。既然有可行性，那么我就寻找“共鸣”了。只有“共鸣”了，我才有继续做大做全的动力，甚至到了这个阶段就不是我一个人的事了，需要更多人参与才能实现。所以，在目前阶段，我主要的精力不会花在我的项目更加规范方面，而是在一点一点小心谨慎地寻求“共鸣”上。
