投产--学到的教训

我最近得到了一份DevOps的工作，主要是在Go中完全从头开始编写一个新的后端系统。这是我从没有在生产中实际使用过，主要是从个人项目中了解到的。

一开始，我们决定简单地坚持使用Go的Http库和一个简单的路由库 -MUX。

记录 - 我想要一些解决方案，可以打印关于每个请求的信息，包括主体参数、身份验证令牌等(用于调试目的)。

更好的错误处理 - 我希望错误仍然是带有错误消息和代码的JSON响应。

我有两个选择：我自己实现上述问题的解决方案，为每个问题使用不同的第三方库，或者选择一个已经完成了大部分(如果不是全部)这些事情的Web框架。

我最终决定使用Echo web框架。有近20000位GitHub明星，一个相当活跃的社区，以及很棒的文档，我认为它是一个很好的工作工具。

我还发现，在使用ECHO编写应用程序时(主要是在解析json正文、编写错误和手动设置标题时)，样板文件会少一些，从而提高了代码的可读性。

但是，当您的端点稍微复杂一些时，就会注意到生产率的真正差异。您经常会遇到需要验证某些JSON字段的情况，并且您会想要有意义的错误消息来描述错误所在。如果您想在没有任何库的情况下做到这一点，您的代码将很快变得更难阅读：

Go Web框架(或Go一般)不强制任何特定的文件结构。如果你曾经使用过像ASP.NET/ASP.NET Core这样的东西，你就会知道我说的是什么，当我说一些框架结构紧凑，许多事情都是按照约定而不是显式指定的时候，你就会知道我在说什么。

关于围棋的事情是，它真的很容易跳过学习结构化你的代码，使它很难阅读和维护混乱。如果你仍然不知道我在说什么，下面是我前段时间写的一个(坏的)围棋终点的例子：

你明白我的意思吗？很可能在添加了所有CreateUser和CreateAgency方法之后，更好的方法总共将包含更多行，但…除外。以后理解、重用、调试和修改这些方法会容易得多，因为每个方法都只有一个目的。如果您还没有，我强烈建议您查看以下资源以获得良好的代码结构：

Https://github.com/bxcodec/go-clean-arch - also一个rest API示例，但更严格地遵循清洁架构的概念。

一般来说，这个概念很简单。您应该将与数据库通信的代码与实际应用程序逻辑本身分开，实际应用程序逻辑本身也应该与传输/端点逻辑(在本例中是HTTP端点)分开。

当我第一次开始使用Go编程时，我希望尽可能少地使用库，所以我当然选择了使用数据库/SQL包(与Postgres一起)。虽然体验还可以，但在查询数据时，我遇到了相当多的样板，特别是必须使用扫描语法。这使我有了以下两个选项：

SQLX- 是一个建立在数据库/SQL之上的轻量级包装器，它带有一些扩展，可以使查询变得更加容易。

GORM-SQLGO的对象关系映射(Object-Relational Map， )库，它根据围棋模型生成SQL模型和查询。

我不认为有一个明确的更好的库，归根结底，它取决于用例和偏好。

GORM可能会让您的生活更轻松，特别是如果您经常忘记在更改数据库之后向查询添加字段(因为在GORM中您根本不需要这样做)。

另一方面，SQLX更多地以SQL为中心，它更像是编写Go代码来与SQL交互，而不是GORM从Go代码生成SQL的方法。如果你喜欢完全控制你的SQL，而不需要学习新的GORM语法，那就好了。

我遇到的挑战之一是为生产配置项目。开发环境和生产环境之间总是有一些不同之处，比如应用程序应该在哪个端口上运行、数据库的主机和凭据等等。

我见过人们通过JSON、YAML，甚至是GOG.go文件来配置他们的应用程序变量。我个人发现env文件工作得最好，尤其是使用docker-compose：

我通常将这些功能与以下实用功能结合使用：构建Docker镜像也非常容易：

我脑海中还浮现出一些我认为不值得在他们自己的栏目中使用的东西：