【问题标题】:Is it okay to store enviornment variables as global variables by reading from file once?可以通过从文件中读取一次将环境变量存储为全局变量吗?
【发布时间】:2021-10-03 14:28:56
【问题描述】:

我有一个具有 SecretKey 的 config.env 文件,每次我想从 JWT(令牌)解析/读取时都需要此密钥的值。
所以,我想到了2可能的方法:

  1. 在代码(.env 文件读取)执行时将 SecretKey 存储为 全局 变量,以便以后使用
    我不知道这是否会超越拥有 .env 文件的全部目的

  2. 每次我想解析令牌时都从文件中读取。 (几乎是每个 API 调用)

那么,1 还是 2?
还是完全不同的东西?

PS 澄清一下,我不是在问是否可以将 env 替换为 global,而是在问我是否可以存储 部署/执行代码后,SecretKey 作为全局变量。

【问题讨论】:

  • 为什么不能将它存储在全局变量中?尝试的时候有没有遇到什么问题?
  • 值得注意的是:环境变量是一个Unix/Linux/others的概念,其中父进程将设置传递给子进程。这种情况只发生一次,在进程创建时。子进程可以随意使用或忽略这些变量,但是一旦创建了子进程,父进程就不能再更改这些(好吧,缺少调试器可能使用的那种深度操作系统魔法)采用)。然而,文件通常可以随时更改,以任何操作系统支持的文件锁定为模,因此.env 文件不同于环境变量。

标签: rest go jwt environment-variables global-variables


【解决方案1】:

是的,你可以存储它,为什么不能呢?

是的,不要在每次需要文件时都读取/解析文件是一个(非常)好主意,这会(可能)明显地使您的 API 调用变慢(取决于它们实际执行的操作)。

您是否需要或应该使用全局变量是另一个问题。通常,不鼓励使用全局变量。这可能是一个很好的例外,尽管您可以选择以其他方式存储它,例如在某种应用程序上下文中,或在实现端点的处理程序的字段中。

【讨论】:

    【解决方案2】:

    关于项目 1

    一般来说,应该避免使用全局变量,因为这会降低代码的可重用性并且更难测试。假设它与该全局变量耦合。它还限制代码一次只能使用一个值:如果需要使用两个不同的SecretKey 值怎么办? 为了解耦代码,可以注入配置值(例如使用结构体或闭包)。

    例如,以下功能与全局变量解耦,它可能是一个准备好重用的包/模块:

    type MyApiCaller struct {
        SecretKey string
    }
    
    func (m *MyApiCaller) DoSomething() {
        fmt.Println("Do something with", m.SecretKey)
    }
    

    现在它可以在任何地方使用,甚至可以作为多个全局变量:

    var Caller1 = &MyApiCaller{"secret1"}
    var Caller2 = &MyApiCaller{"secret2"}
    

    这也很容易测试,因为状态不是通过全局变量共享的。

    关于项目 2

    每次需要值时读取配置文件可能会限制程序性能,因为磁盘访问非常昂贵。横向优势是程序无需重新启动即可获得最新配置。

    【讨论】:

    • In general, global variables should be avoided because makes the code less reusable and more difficult to test. 也许那段代码不需要可重用。也许它不需要两个值。也许永远不会使用这种增加的复杂性!
    • 当然,这一切都取决于几个因素,项目有多大,它的可测试性/可重用性如何......
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2017-05-26
    • 2017-03-06
    • 1970-01-01
    • 1970-01-01
    • 2022-01-08
    • 2021-05-10
    • 1970-01-01
    相关资源
    最近更新 更多