# 1.2 项目背景

概是在2017年4月份,我们团队整个开发方式都决定使用前后端分离的方式来合作开发,前后端分离当时整个技术方案也是由我来负责整理,探索,如何让整个团队更高效的开发,完成自己的本职工作.从一开始的jsonp,到后面nginx反向代理,这里面我也收获了很多东西,也写了一些相关的博客总结,

但最让人头疼的还是前后端如何针对接口来对接,当时找了很多解决方案,一开始使用的是叫apidocs (opens new window)的,有些类似于写java的注释,使用起来还是不错的,不过没有在线生成的,文档写完后需要单独命令来生成一个文档,挺麻烦,后来就放弃了

最终就考虑使用Swagger来做文档的这块,但Swagger大家都知道,Swagger的ui虽然能把文档说清楚,但是不怎么好用,可能不适合我们国人的眼光吧,至少我是这么认为的,所以当时也就想看看Swagger的生成方式,Knife4j的前身swagger-bootstrap-ui就因此诞生了

这里谈谈swagger,虽然很多人喷他,不好用,基于注解,代码入侵很强,等等 很多原因。但总体来看,swagger发展至今,包括在各个语言,NodeJs.netjavaphp等等,它可以说是一个有些接口规范的东西,从开始,到一步步规范,其实是一个很艰难的过程,任何事物,都不是尽善尽美的,swagger也是一样,至少它给这么多语言提供了一种文档生成的解决方案,其价值就远超它本身的缺点

在Java里面,是Springfox实现了swagger的接口方式(Spring框架几乎统一了Java端Web层框架的实现),其他语言也类似.

我一直觉得如果前面有人开发出来这个东西,而且用户范围,稳定性都相对较高的情况下,这个东西一定是有他的意义存在的,站在巨人的肩膀上,做正确的事,一直是我认为符合实际情况的,起码你不用自己填坑,因为,做开源,一个想法在当时,可能比较新颖,关注度很高,但是我想,大部分人都逃离不了惰性,缺少的是持之以恒,特别是在中国,很多开源其实都是个人在做(包括目前的Knife4j),意识上,相对国外还是比较薄弱的,而且还有精力,锲而不舍的精神,任重而道远矣~!

但随着项目的发展,仅仅一个swagger-bootstrap-ui皮肤已经不能满足开发者的需求,需要增加更多的服务端代码来满足开发者的需求,所以,作者决定从更名开始,一个新的名字也代表着进入新纪元,Knife4j正式走上了开发者的视野。

所以,Knife4j不仅仅将前身的Ui皮肤通过Vue技术栈进行了重写,也增加了更多个性化的特性增强功能,基于springfox项目以及OpenAPI的规范,希望为Swagger的生态发展做一份贡献。

Knife4j开源至今也有三年半有余了,为自己一直坚持下来打call,也会一直坚持下去,继续维护它,东西虽小,但坚持下去总会有收获.

被围观 人次
上次更新: 2020-11-6 19:51:33
有任何问题请使用Knife4j的标签在OSC社区