近期项目组准备做一个新的工具,因此自个儿做的start-fastapi框架正好能派上用场试试水。在起草需求搭建最初框架的时候也逐步发现原先的start-fastapi有一些不足的地方,因此做了一些针对性的优化。
首先必须重新介绍一下start-fastapi,其本身是轻量级web框架fastapi的延伸,但是由于fastapi给的例子过于简单,因此就基于此做了一个简单的web后端脚手架,借鉴了eggjs的目录组织模型,使得整个框架更加易于投产。如果稍微看过start-fastapi其中的代码的话就能够发现它并不是一个OOP的框架,这是因为一方面python本身不是向java一般与OO设计理念强耦合,且其module隔离与动态加载机制已经足够区分每一个功能模块了;另一方面轻量的HTTP Web Server本身作为无状态的服务,各个功能模块应该是静态式、单例式的存在。在start-fastapi上也可以继续扩展底层。从起草工具的效果来看,多人协同开发时,每个人负责的模块应当也不会有太大冲突的概率。
接下来是近期优化的一些点,首先是application目录下的优化。原先application分为了service、middleware、config等多个模块,但现在直接缩减为controller、logger跟router,这是因为service跟middleware里全局性的功能模块一般都是用户自定义的,而controller的response可以约定,logger factory也可以统一提供。而router作为后端app的固有功能,这块就必不可少了。