前言
我第一次知道 amis 这个项目应该在 19 年的时候，那会 amis 才开源时间不长，除了百度内部用之外，几乎没有听过那家公司有使用案例，所以也没有做过多关注（即使到了现在各种程序员社交平台上的讨论也绝不算多）。
后来在深圳一家公司的工作经历接触到了 LowCode 这个概念，相应的对 amis 也有了一定的关注，但还是因为没有听过太多公司的应用案例，所以也没想过 用在日常的项目开发中。
然后就到了去年（2021年）在深圳找工作面试过程中，通过与面试官交流技术栈，发现有一些公司有使用 amis 去构建自己的一些中后台项目。之后就有了用 Amis 构建一个后台项目的想法。
Tpamis
在项目的开发初期发现目前没有 基于 PHP 和 Amis 这两个技术栈的开源项目，甚至基于 Amis 的衍生开源项目也很少。于是就打算将写的这个项目开源，即使直接使用我这个开源项目的人不多，也希望可以提供一些借鉴的方案。
就这样经过半年的迭代项目的功能也逐渐完善，取名 Tpamis 开源到了 github 和 gitee 上。
关于项目的具体信息，可以关注：https://gitee.com/dbkuaizi/tpamis 和 https://github.com/dbkuaizi/tpamis 这里不做赘述。
随着 Tpamis 开发的过程，对 amis 的了解也逐渐的加深，用一句话来总结就是: Amis 像是一座功能完善的围城，在城内提供了绝对数量的组件可以满足 80% 甚至 90% 的功能。但 Amis 没有的功能组件，对于后端来说就是无法实现的。(毕竟有专业前端支持的项目，又为什么会选择 Amis 呢)。
举几个例子：
- Tpamis 没有多标签页的功能，并不是我不想做进去，而是通过 jssdk 的开发方式，不支持这个功能。
- 在移动端模式下，个人主页和退出登录按钮是显示在页面菜单上面的， 原因也是因为 amis jssdk 没有提供相应的功能。
当你遇到上面的问题时，有两种解决方法，一种是像我一样换一个方式实现这个功能，另一种就是找前端去写 react 的代码，扩充 api 或者扩充组件的功能。
amis 的优缺点
经过 tpamis 的开发，我把我认为的优点和缺点总结一下，希望可以对你是否选择 amis 提供一些参考。
优点
- 足够多的组件支持，按照官方的说法 目前提供了 120+ 组件，如果只是做内部的中后台管理系统，组件绝对是够用的状态。
- JSON 化构建页面，整个过程中无需前端人员参与，后端开发者通过 JSON 配合 amis 官方文档，即可实现页面。
- Echarts 支持，由于是百度的中后台项目，所以对 Echarts 支持度很好。
- 有大厂背书，更新频率也不算低，不用担心忽然不维护。
缺点
- 组件即围城，正如我上面所说，如果你需要一个组件目前没有支持的功能，那么要么选择 react 自行开发，要么选择通过其他组件来实现这个功能，不过好在组件很多，总有可以替代的方式。
- JSON 构建页面，JSON 是个双刃剑，既降低页面的开发难度，也限制了页面的可能性，如果你需要在实现一个比较复杂的功能，那么你需要写出很复杂的JSON 来实现它，例如 Tpamis 的登录页面，就是混合了 HTML、JS、CSS、JSON 才实现的效果。
- 社区活跃度极差，在开发的过程中遇到解决不了的问题（组件Bug、文档不完善等），加过官方的交流群、也提过 Issues，但基本上都没有任何回应。也就是说 一旦你开发中遇到了问题，95% 的可能性只能自己解决。
- 细小的 Bug，组件数量达到这个量级，出现 bug 也是在所难免的。但问题在于 amis 开源版的使用者大部分都是纯后端开发者，没有能力去修复这些bug 只能等待官方处理。（这里大家可以去看一下 amis 的 issues，很多 bug 的提问并没有得到官方的答复：https://github.com/baidu/amis/issues ）
总结
Amis 好用吗？
如果你们项目对后台的需求只有增删改查，那么无疑 Amis 的很不错的一个选择，减少了后端开发写页面的负担。
我会在工作中选择 Amis 吗？
目前为止，我不太建议在工作中使用 Amis 来开发正式项目。毕竟一个没有社区积极的支持，出了问题只能靠自己。我不想在自己负责的项目中引入这些隐患。
对于 Amis 还有其他选择吗？
Amis 其实是百度爱速搭项目的一个衍生开源项目，爱速搭毕竟是商业项目，必然有着更好的商业支持，也是一个不错的选择。
上面的这些内容只是出于在这个阶段对于 amis 的感受，或许在后期的迭代中，Amis会有更完善的生态体系，让它变成一个不错的选择。