大家好，我是程序员Spectre。用Go编写API服务，许多语言新手问的第一件事是：“我应该使用哪个框架？”。来自Ruby或Python等语言的人可能熟悉大多数开发人员使用的单一Web框架，例如Rails、Django或Flask。Go有点不同，因为社区中确实没有最流行的单一框架。虽然有多种可用的框架，我将在本文中讨论其中的许多框架，但Go社区在构建API服务时似乎并未就“首选”框架（如果有）达成一致。虽然我不会在这篇文章中比较或推荐任何特定的框架，但我会尝试通过介绍在为您的下一个GoAPI项目选择框架时应该考虑的四个关键事项来给您一个想法。01你真的需要框架在用Go构建API后端服务时，当你试图决定使用哪个框架时，首先要问自己的是，你需要框架吗？Go标准库很棒，它提供了许多开箱即用的世界级API所需的组件！我在Go中设计并构建了一项服务，每天仅使用Go标准库+路由器/mux处理数百万个请求。两个最流行的路由器是：gorilla/mux[1]chi[2]这两个库都提供基于URL主机、路径、标头、HTTP方法和查询值等内容的快速请求路由，同时允许您定义自己的“自定义”“匹配器。这些路由器提供比内置的http.ServeMux[3]更好的体验，因为它们允许将您的请求路由到不同的处理程序，而无需复杂的if或switch块，例如：func(b*bookServer)bookHandler(whttp.ResponseWriter,req*http.Request){//howyou'dhavetoimplementmethodbasedroutingifusingonlythestdlibifreq.URL.Path="/books/"{ifreq.Method==http.MethodPost{b.createBook(w,req)}elseifreq.Method==http.MethodGet{b.getAllBooks(w,req)}elseifreq.Method==http.MethodDelete{b.deleteAllBooks(w,req)}else{http.Error(w,fmt.Sprintf("expectmethodGET,DELETEorPOSTat/books/,got%v",req.Method),http.StatusMethodNotAllowed)return}}}EliBendersky有一个很棒的系列[4]关于在Go中构建RESTAPI，从标准库开始然后介绍路由器（例如gorilla[5]或chi[6])，最后切换到使用完整的Web框架。本系列展示了完全坚持使用标准库的一些缺点，以及其他库（例如上面的两个路由器包）如何非常有用。虽然这两个路由器都带有中间件来处理基本身份验证、CORS协商、请求日志记录等事情，同时还允许您轻松集成自己的路由器，但它们仍然不是框架。如果你的API足够简单，或者特别是如果你或你的团队刚刚开始使用Go，我建议从标准库+路由器/多路复用器开始，看看你需要多长时间才能使用完整的框架。这种方法将使您能够学习基础知识，而不会被更复杂框架的细微差别所困扰。02你自己的选择如果你决定你仍然想为你的新服务使用web框架，有几个流行的选择，包括：echo[7]gin[8]buffalo[9]这些项目可以被描述为完整的web框架，因为它们处理的不仅仅是路由和中间件。它们为服务的其他方面提供内置和预配置的功能，例如：日志记录模板国际化数据验证资产服务数据库访问和ORM等。如果您只想开始编写应用程序的业务逻辑而不用担心一些的实现细节，这可能非常有用，但它确实是有代价的：你很可能会被框架的选择所困。不喜欢echo[10]格式化日志的方式？想要使用不同于buffalo[11]选择的路由器吗？我并不是说在使用这些框架时不可能交换依赖关系，但这可能很困难，因为几乎框架的全部意义在于为您做出这些选择。如果您或您的团队对框架选择的依赖项感到满意，那么它可能非常适合您的场景，事实上，它可以提高工作效率。但是，如果您是那种喜欢挑选依赖项并时不时调整或替换它们的人或团队，您可能很快就会发现框架不是您的最佳选择。也就是说，你喜欢DIY~03ProjectPulse(Pulse)查看GitHub上项目的未解决问题的数量以及项目维护者对这些问题和PR的响应程度也是需要牢记的重要“软”指标。虽然有大量未解决的问题并不一定意味着项目不好，但这可能意味着某些功能或内部工作不明确并且没有尽可能地记录下来。**注意：**情况并非总是如此，因为这也可能意味着该项目正在获得动力并且人们很高兴贡献新功能。打开问题和PR以查看项目的进展情况。然而，如果项目维护者似乎与社区没有良好的关系，或者如果他们不经常回复问题或讨论，这可能意味着您可能会发现自己在等待答案或错误修复被合并您选择的特定框架。GitHub有点被忽视的脉搏视图[12]可以帮助显示项目的活跃程度以及问题打开和关闭的频率。大多数流行的框架也会有专门的Gitter、Discord或Slack，因此也值得一试，看看社区对新手有多大帮助。04未来最后，可能值得将您选择的框架的受欢迎程度与其他框架进行比较，因为受欢迎程度下降可能意味着随着社区转向另一个解决方案，该项目可能会被放弃或停滞。虽然GitHub上的星数是项目受欢迎程度的一个不错指标，但它并不能告诉您趋势如何改变Google趋势搜索的方式。这是一个谷歌趋势搜索的例子，比较了过去一年美国对golangecho和golangbuffalo[13]的兴趣。GolangEcho与GolangBuffalo搜索趋势在r/golang[14]中搜索您选择的框架也可能会让您与社区中的其他人对该项目的实用性和潜在未来产生一些分歧。虽然这不是确切的证据，也没有人知道未来，但如果框架开始消亡或仍然强大，这种策略以及上面提到的观察项目脉搏应该会给你一个相对好的想法。如果您代表您的团队为工作项目选择框架，这一点尤为重要，因为我们中的许多人都处于不得不维护构建在不再收到任何错误修复或安全程序更新的框架之上的应用程序的不幸境地.还值得检查框架的文档，看看它是否是最新的，以及是否有任何最近发布的使用相同框架和主要版本的教程。如果没有人在网上撰写有关它的文章，则可能表明它不如以前那么好。这就是选择标准库相对于第三方框架的优势，因为标准库永远不会消失，也不会发生太大变化。总结一下性能，我认为框架作者[15]钦佩[16]的一个“特性”就是性能。虽然性能很重要，但我不认为选择Web框架主要是为了“性能”最好，尤其是在Go中。Go已经非常快了，你的框架代码很可能不会成为你应用程序的瓶颈。在您需要开始分析和优化您的框架之前，数据库、网络或您自己的应用程序代码通常是服务性能问题的根源。虽然知道您选择的框架比另一个框架更快可能感觉很好，但如果快10毫秒，您的用户可能永远不会注意到。结论简而言之，选择适合您或您的团队的框架（或不适合），因为没有适合所有人的“正确”答案。如果你决定你真的想使用一个框架，我建议你至少选择两个并在两个框架中实现相同的简单CRUDAPI，看看你更喜欢哪个。您同意还是不同意本文中的观点？您和您的团队尝试过哪些框架？你最喜欢哪一个，为什么？原文链接：https://dev.to/markphelps/4-things-to-consider-when-choosing-a-go-api-framework-4bei参考文献[1]gorilla/mux：https://github.com/gorilla/mux[2]chi:https://github.com/go-chi/chi[3]http.ServeMux:https://pkg.go.dev/net/http#ServeMux[4]很棒的系列：https://eli.thegreenplace.net/2021/rest-servers-in-go-part-1-standard-library/[5]大猩猩：https://github.com/gorilla/mux[6]chi：https：//github.com/go-chi/chi[7]回声：https://github.com/labstack/echo[8]gin：https://github.com/gin-gonic[9]buffalo：https：//github.com/gobuffalo/buffalo[10]echo:https://github.com/labstack/echo[11]buffalo:https://github.com/gobuffalo/buffalo[12]脉冲视图:https://github.com/gin-gonic/gin/pulse/monthly[13]golangecho和golangbuffalo：https://trends.google.com/trends/explore?geo=US&q=golang%20echo,golang%20buffalo[14]r/golang：https://www.reddit.com/r/golang[15]过度：https://github.com/gin-gonic/gin#benchmarks[16]推崇：https://github.com/labstack/回声#benchmarks
