rest - 如何在现实世界的 Go 项目中分离路由、处理程序、第 3 方接口(interface)和业务逻辑

Question

看完official guide关于如何构建项目和经历各种(1、2、3 仅举几例)示例和项目我不禁想知道我构建 REST-API 服务器应用程序的方法是否结构化 正确地。

API 的用途是什么？

POST /auth/sign-in

接受用户名和密码并发出JWT (JSON 网络 token )。

GET /auth/sign-out

将 JWT 添加到黑名单以使身份验证 session 无效。

获取/资源

检索所有资源的列表。

POST /resources(需要有效的 JWT 身份验证)

接受 JSON 正文，创建新资源并向所有人发送有关新资源的电子邮件和通知。

我的项目是什么样的

目前我没有创建任何库。一切都在主包中，带有路由的总体服务器设置等都在 main.go 中完成。我没有选择在 Rails 或 Django 中找到的 MVC 模式，以避免仅仅为了它而使事情过于复杂。另外我的印象是它并不真正符合 guide 中描述的命令和库的推荐结构。上面已经提到了。

auth.go # generates, validates JWT, etc
auth-handler.go # Handles sign-in/out requests; includes middleware for required authentication
mailer.go # Provides methods to send out transactional email, loads correct template etc.
main.go # set up routes, runs server; inits mailer and notification instance for the request context
models.go # struct definition for User, Resource
notifications.go # Provides methods to publish push notifications
resource-handler.go # Handles request for resources, uses mailer and notifications instances for the POST request

它应该是什么样子的？

路由应该分开吗？中间件呢？以及您如何处理与第 3 方代码的接口(interface)——想象一下概述的示例应用程序中的 mailer.go 与 Mandrill 对话以及 notifications.go 与 Amazon AWS SNS 对话？

Answer 1

我可以分享一些我自己的经验。

1. 在应用程序代码中:

   • 与库代码相反，分成包和子包不太重要 - 只要您的代码没有太复杂。我主要将应用程序设计为集成自包含库，因此应用程序代码本身通常很小。一般来说，如果你真的不需要它，尽量避免包分离。但不要只是在一个包中塞入大量代码 - 这也很糟糕。

   • 但没有像“util”这样的通用包，它们很快就会开始积累包袱并变得糟糕。我有一个单独的 repo，用于跨项目可重用的通用实用程序，在它下面，每个实用程序 API 都是一个子包。例如github.com/me/myutils/countrycodes，github.com/me/myutils/set，github.com/me/myutils/whatevs .

2. 无论包结构如何，最重要的是将内部 API 与处理程序代码分开。处理程序代码应该是一个非常薄的层来处理输入，并调用一个内部的、自包含的 API，可以在没有处理程序的情况下进行测试，或者绑定(bind)到其他处理程序。看起来你正在这样做。然后您可以将您的内部 API 分离到另一个包中，这并不重要。

3. 当您决定应将代码的哪些部分分离到库中时，请从代码重用的角度考虑。如果此代码仅供您的应用使用，则没有任何意义。

4. 我喜欢将与第三方 API 的集成封装在一个定义在二级包中的接口(interface)中。例如，如果你有类似使用 AWS SES 发送电子邮件的东西，我会创建一个名为 github.com/my_org/mailer 的包，它有一个抽象接口(interface)，在它下面有一个 github.com/my_org/mailer/ses 实现 SES 集成的包。应用程序代码导入了 mailer 包及其接口(interface)，只有在 main 中我才以某种方式注入(inject) SES 的用法并将它们集成在一起。

5. re 中间件 - 我通常将它与 API 本身放在同一个包中。