cg33

第一次,站长亲自招 Gopher 了>>>

作为一个 go 开发者,如果告诉你编写好代码后,不用编译不用打包,在本地写完代码即可马上发到远端运行;要调试某个结构体方法某个 rpc,不用写 debug 日志,直接本地可以调用并运行。你觉得怎样? 这不是想像,而是 go-plugify 能做到,且致力于让你在分钟级的时间内做到的事情。 具体怎么做,请访问 github 仓库:[https://github.com/go-plugify/go-plugify/blob/main/README_CN.md](https://github.com/go-plugify/go-plugify/blob/main/README_CN.md) ## 为什么 go 俨然是近年来最流行的应用服务端开发语言之一了,因为其各种优良的特性。但作为一个编译而非解释型语言,我们避不开编译部署的问题。相比于 php/python 等动态语言,编译当然可以提前检测出包括语法错误等问题,但我一直觉得为了小的功能或修复去编译整个程序怎么看都是低效的。在程序不大,功能不多的情况下仍可接受。但当你程序逐渐变大,功能越堆越多时,整体编译的收益越来越低。 这时候,脚本或插件化的策略无疑是一个选项,当然你需要平衡开销。尽管不是刚需,脚本与插件在很多场景下其实是有更大的作用与价值的。这时候,我也开始了解和寻找 golang 插件框架,但我发现这么多年了,竟没有开源的成熟的规范和框架。当然有一些好的实践,但仍没有形成统一的规范和易用的框架或流程。这意味着,可能我们有很多" 无效 "的时间其实都被浪费在了编译部署这些事情上。作为一个对效率非常敏感的人实在很难接受。 其实,golang 官方是有支持 plugin 的包的,但这个包有很多限制,比如只能在 linux/mac 系统下使用,且插件和主程序必须使用相同版本的 golang 编译,否则会报错等问题。所以被很多人吐槽也流行不起来。为什么会这样呢,我猜就是 go 官方非常的固执和别扭在这件事情上,毕竟这是一个 "违背" 他们设计初衷的事,所谓: "Do not communicate by sharing memory; instead, share memory by communicating" 的理念的设计。 但固步自封是很糟糕的,哲学只能在问题中升华提炼,总是要找到更好的解决方法才行。 就如同多年前我创作了 go-admin 一样,那时候也是展望整个 golang 生态,没有一个成熟的后台管理框架,所以我才去创作了 go-admin,推动 golang 后台管理框架的发展。而现在的情况很类似跟当年的情况,唯一变的就是现在氛围不像当年那么浓厚,各种关于 go 的交流群,现在大家的关注点都在 AI,但 AI 也在逐渐偃旗息鼓,因为大家发现它仍然不能取代程序员甚至也取代不了 golang,所以回过头我们还是得想办法去解决问题。 而为了解决这个问题,我编写了 go-plugify,目的是想创造一个 golang 的插件框架与平台,希望能够提供易用好上手的流程与工具帮助到社区。 ## 怎么做 目前实现插件的方法大致有几种: - 使用原生的 golang plugin - 使用 golang 编写的解释器 - yaegi - golua - gopython - 使用 wasm 这些方法各有优劣,但也都能在一定程度上实现脚本插件化。可以根据自身的情况来选择。go-plugify 不会限制哪一种方法,而是应该对能支持的方法都进行支持,让使用者可以根据自身情况更好的选择某一种语言某一种方法。go-plugify 实现的是接口与规范,以及提供更好易用的工具能力。 基于此,还需要考虑到用户现有的项目。不管是何种的 web 框架,也都应该予以支持,因此,go-plugify 不会限制于你是使用哪一个的 web 框架,而是通过适配器的模式对各个框架都进行支持。使得你可以很简单的接入您的项目,马上拥有插件能力,拥抱未来广阔的插件生态,省却开发编译等等时间。

有疑问加站长微信联系(非本文作者)

335 次点击

框架 github web 代码

• 编辑
• 预览