创作背景

1. go-scaffold

近年来，我们团队陆续在尝试用 go 写项目，起初都是基于 beego 来开发，不过 beego 的内置 ORM 用起来并不那么顺畅，一些基础包如 redis，kafka，mongo 等也没有，每次新开一个项目都需要重新组织一遍代码。

虽然 beego 没有，但是社区有啊，于是我们诞生了一个想法，我们不再使用框架，而是创建一个脚手架，把社区里最优秀的包组装在一起，就像哆啦A梦的百宝袋一样。

这样每次新的项目都可以基于这个脚手架(或者叫模版)来构造，而项目只需要关注业务本身。我们一边讨论设计这个脚手架的代码组织结构，一边选型基础依赖的包。

路由本来选的是 beego 的路由，在我们改造 beego 路由的时候，始终有些别扭，我们发现，路由直接使用 gin 似乎更轻量一些，我们也不必为导入整个 beego 的包产生心理负担了。

配置文件我们采用 viper 这个包来读取，并且选用 toml 这个最简约，最强大的格式作为默认配置文件后缀。

日志选用的 logrus，但是它没有日志切割，归档功能，lumberjack 包完美解决这个问题。

数据库 ORM 社区 star 最多的是 gorm，但是我们体验一番后，发现 xorm 更符合我们之前的书写风格，于是选用了 xorm。

redis 包有 redigo 和 go-redis 两个选择，根据之前项目的使用经验，redigo 要更稳定一些，于是采用了 redigo。

grpc 自然要选用官方 grpc。

因为要支持命令行功能，我们封装了 cobra 包。

因为要支持定时脚本任务功能，我们封装了 cron 类库。

基本上核心的功能都有了，于是我们在内部仓库创建了一个项目，取名叫 go-scaffold，恰逢今年年初我们团队在支持智慧城市的项目，基于这个脚手架我们创建了三个项目。

我们在开发新项目的同时，也在调整 go-scaffold，因为之前我们定位它是脚手架，所以它的代码在每个项目里面都有一份。这样一来每次改动脚手架，我们都需要在三个项目里面改一遍。

一段时间下来，我们开始重新思考 go-scaffold 的定位，虽然我们极不愿意把它当一个框架来看待，但似乎把它做成框架的形式，后续的开发要更方便一些。

重新组织代码之后，我们在公司内部仓库建了一个新项目，取名叫 yago。

可是很快我们又遇到了新的问题，由于众所周知的墙的问题，我们在 go get 拉取依赖包的时候，必须要指定 GOPROXY 代理，在 go 1.13 之前又无法设置 GOPRIVATE，这样一来我们就拉不到内部仓库的包了。

所以我们向组织申请将它在 github.com 上开源了。

之所以取名叫 yago，灵感来源于鸟哥的 yaf 框架(yet another frame)，表达一种简洁，低调，朴实，但是又很好用的中心思想。而且 yago 写起来还很顺手。

说到取名，我不得不说，我们开发团队的「晓」是个取名的好手，之前的 go-scaffold 和 yago 都是出自他的手笔。