NodeJS Express中每个请求的全局范围 [英] Global scope for every request in NodeJS Express

问题描述

我有一个基本的快速服务器，需要在每个请求处理期间存储一些全局变量。
更深入地，请求处理涉及许多需要存储在变量中的操作，例如 global.transaction []

当然，如果我使用全局范围，每个连接将共享其事务的信息，我需要一个全局范围，因为我需要访问事务数组在许多其他模块中，在执行期间。

有关这个问题的任何建议？我觉得是非常微不足道的，但我正在寻找复杂的解决方案：）

非常感谢！

更新
这是一个案例，更清楚。

在每个请求中，我有3个模块（ ModuleA ， ModuleB ， ModuleC ），它读取10个随机文件的内容一个目录我想跟踪每个请求读取的文件名称列表，并以 res.write 列表发回。

所以 ModuleA / B / C 需要访问一种全局变量，但是列出 request_1 request_2 ， request_3 等...不必混合。

解决方案

这是我的建议避免全球状态像fire 。

• 从我的经验来看，这是Node服务器中的第一个维护问题。


• 它使您的代码不可复制，难以重用。


• 它在你的代码中创建隐式的依赖关系 - 你永远都不知道哪一个取决于哪个是不容易的。

你希望每个应用程序使用的代码部分尽可能地显式。这是一个巨大的问题。

问题

多个请求并据此采取行动。这是编写软件的一个很大的问题 - 有些甚至说最大的。

某些解决方案

有几个对象在应用程序通信中的重要性不能被高估在Node服务器中跨请求或服务器端完成共享状态的方法。这取决于你想做什么这是两个最常见的imo。

1. 我想观察请求的作用。


2. 我想要一个请求，根据另一个请求做的事情。

1。我想观察请求的做法

再次，有很多方法可以做到这一点。这是我看到的两个。

使用事件发射器

这种方式请求发出事件。应用程序读取请求触发的事件，并相应地了解它们。应用程序本身可以是您可以从外部观察到的事件发射器。

您可以执行以下操作：

  request.emit（客户做了一些傻事，theSillyThing）l 
  

然后从外面听它 if您选择。

使用观察者模式

这就像一个事件发射器，但是反转。您可以在请求上保留依赖关系的列表，并在请求中发生有趣事件时自己调用处理程序方法。

我个人通常更喜欢事件发射器，因为我认为他们通常更好地解决问题。

2。我想要一个请求，根据另一个请求做的事情。

这不仅仅是听，再次，这里有几种方法。他们的共同点是我们将共享放在

而不是拥有全局状态 - 每个请求都可以访问服务 - 例如，当您阅读通知服务的文件时，何时需要读取文件的列表 - 您要求服务。一切都是依赖的。

服务不是全局的，只是它的依赖。例如，它可以协调资源和数据，作为某种形式的存储库）。 p>

尼斯理论！现在我的用例怎么样？

这里有两个选项可供你在这种情况下使用。这不是唯一的解决方案。

第一个选项：

• 模块是一个事件发射器，每当他们读取一个文件，他们发出一个事件。


• 一个服务监听所有的事件并保持计数。


• 请求可以显式访问该服务，并可以查询它的文件列表。


• 请求通过模块本身进行写入，而不是添加

第二个选项：

• 创建一个拥有module1，module2和module3的副本的服务。 （组合）


• 该服务根据需要将操作委托给模块。


• 该服务保留自


• 请求直接停止使用模块 - 使用服务。

这两种方法都有优缺点。可能需要一个更复杂的解决方案（这两个在实践中很简单），其中服务被进一步抽象，但我认为这是一个好的开始。

I have a basic express server that needs to store some global variables during each request handling. More in depth, request handling involves many operation that need to be stored in a variable such as global.transaction[]

Of course if I use the global scope, every connection will share information of its transaction and I need a global scope because I need to access the transaction array from many other modules, during my execution.

Any suggestion on this problem? I feel like is something very trivial but I'm looking for complicated solutions :)

Many thanks!

UPDATE This is a case scenario, to be more clear.

On every request I have 3 modules (ModuleA, ModuleB, ModuleC) which read the content of 10 random files in one directory. I want to keep track of the list of file names read by every request, and send back with res.write the list.

So ModuleA/B/C need to access a sort of global variable but the lists of request_1, request_2, request_3 etc... don't have to mix up.

解决方案

Here is my suggestion avoid global state like fire.

• It's the number one maintenance problem in Node servers from my experience.
• It makes your code not composable and harder to reuse.
• It creates implicit dependencies in your code - you're never sure which piece depends on which and it's not easy to verify.

You want the parts of code that each piece of an application uses to be as explicit as possible. It's a huge issue.

The issue

We want to synchronize state across multiple requests and act accordingly. This is a very big problem in writing software - some say even the biggest. The importance of the way objects in the application communicate can not be overestimated.

Some solutions

There are several ways to accomplish sharing state across requests or server wide in a Node server. It depends on what you want to do. Here are the two most common imo.

1. I want to observe what the requests do.
2. I want one request to do things based on what another request did.

1. I want to observe what the requests do

Again, there are many ways to do this. Here are the two I see most.

Using an event emitter

This way requests emit events. The application reads events the requests fire and learns about them accordingly. The application itself could be an event emitter you can observe from the outside.

You can do something like:

request.emit("Client did something silly",theSillyThing)l

And then listen to it from the outside if you choose to.

Using an observer pattern

This is like an event emitter but reversed. You keep a list of dependencies on the request and call a handler method on them yourself when something interesting happens on the request.

Personally, I usually prefer an event emitter because I think they usually solve the case better.

2. I want one request to do things based on what another request did.

This is a lot tricker than just listening. again, there are several approaches here. What they have in common is that we put the sharing in a service

Instead of having global state - each request gets access to a service - for example when you read a file you notify the service and when you want a list of read files - you ask the service. Everything is explicit in the dependency.

The service is not global, only dependencies of it. For example, it can coordinate resources and the data, being some form of Repository).

Nice theory! Now what about my use case?

Here are two options for what I would do in your case. It's far from the only solution.

First option:

• Each of the modules are an event emitter, whenever they read a file they emit an event.
• A service listens to all their events and keeps count.
• Requests have access to that service explicitly and can query it for a list of files.
• Requests perform writes through the modules themselves and not the added service.

Second option:

• Create a service that owns a copy of module1, module2 and module3. (composition)
• The service delegates actions to the modules based on what is required from it.
• The service keeps the list of files accessed since the requests were made through it.
• The request stops using the modules directly - uses the service instead.

Both these approaches have advantages and disadvantages. A more complicated solution might be required (those two are in practice pretty simple to do) where the services are abstracted further but I think this is a good start.

这篇关于NodeJS Express中每个请求的全局范围的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！