联合开发的智能门锁应用原型
Flask Application Builder，简称F.A.B。是基于Python Flask框架之上的开源应用。我现在拿来用于智能门锁等物联网的应用服务器的原型开发。
为何分成设备服务器和应用服务器？
物联网与互联网（及衍生的移动互联网）不同，因为物联网还需要接入设备。设备端开发周期远远长过网站开发周期。这两者的需求不一致：设备端要求稳定，网站需要快速迭代适应市场。
再加上分布式设计是规模扩张的技术基础，所以一开始就展开分布式设计很合理。
智能门锁
智能门锁技术很简单，围绕着简单的开关和门磁传感器而展开。但是针对B端需要提供非常灵活的定制服务，以服务自住（开发商）、长租（租售同权）、短租（OTA在线旅游）、仓储（工业门等）。还要支持不同的OTA平台，第三方认证（微信、支付宝以及企业LDAP服务器等），所有这些都和业务流程、组织机构、权限管理业务层面紧密相连。所以选择一个在RBAC方面颗粒比较细的框架可以节省不少事情。
Flask & F.A.B
Flask，包括几本相关书籍，从一开始就是基于数据库设计的权限管理。而F.A.B则将权限管理自动化了，并提供了基于Method颗粒的管理。所以F.A.B很合适。
当然，细颗粒的权限设计必然需要反复读取数据库。在系统启动速度上，Flask的确和Cyclone/Twisted不在一个数量级上。不过启动后，速度还行。但是我觉得应该采用Redis Cache部分RDBS访问，并使用gevent升级。
已测试实验
- 主题切换，部分配色需要更新。
- 多语种切换，需要重新收集词汇进行翻译。
- 客户化网页设计，头部导航菜单等，这部分比较熟练了。
- 权限设置，非固化设置在代码中，而是写入到数据库中，也是速度慢的主因。
- 模型视图与ORM集成，的确功能比较强大，直接对应生成REST API和CURD视图，可以定制。但是还需要很多工作。
- 灵活的检索框。
待完成
- Dashboard即仪表盘设计，即JS/CSS客制化；
- 权限的表达（图表）、申请和授权，需要更新ER图；
- 使用率的表达（图表），需要替换Google Chart，重新定义ChartView；
- API的集成，重新定义REST API的架构。
- 与设备云API的整合。
- hash的使用。
- 从sqlite3到MySQL/Maria/Redis的整合。
F.A.B的使用观感
- 慢，尤其是启动速度特别慢，与RBAC颗粒比较细，而且全部基于关系数据库有关联。
- ORM虽然方便，基于列表和表单管理资源，更加适合于桌面浏览器中作为管理员界面。
- 前台用户界面，则可能需要额外开发一套模板，以大图标和JavaScript实现面向移动界面，好在工作量尚可。
- REST API不完全符合规范，很让人郁闷。
- ORM做了太多自动化工作，需要仔细查看文档。
- 太多国外组件，需要兼容国内的图形库和第三方认证。
