中登托管行结算路径_在非根路径上托管Next.JS应用-CSDN博客

中登托管行结算路径

How to serve your next.js app from example.com/front-end instead of the assumed example.com/ root path.

如何从example.com/front-end而不是假定的example.com/根路径为您的next.js应用提供服务。

This article uses the Korerorero project as an example. Korerorero is an open source implementation of an animated chatbot with voice recognition.

本文以Korerorero项目为例。 Korerorero是具有语音识别功能的动画聊天机器人的开源实现。

When korerorero-front-end is deployed using the docker-compose config in korerorero-reverse-proxy it is served from /front-end rather than the root /.

当使用korerorero-reverse-proxy中的docker -compose配置部署korerorero-front-end时，它是从/front-end而不是根目录/ 。

This breaks some assumptions about where things will be in the file hierarchy.

这打破了关于事物将在文件层次结构中的位置的一些假设。

To counter this we need to tell the framework that some of the assets are located somewhere other than root /.

为了解决这个问题，我们需要告诉框架某些资产位于root /其他位置。

To do this we set SELF_PATH in .env like so:

为此，我们在.env中设置SELF_PATH ，如下所示：

.env (.env)

Source: https://github.com/nzcodarnoc/korerorero-reverse-proxy/blob/v0.3.2/front-end.env.example

资料来源： https : //github.com/nzcodarnoc/korerorero-reverse-proxy/blob/v0.3.2/2/front-end.env.example

Then, over in next.config.js we can tell the framework about the novel path.

然后，在next.config.js我们可以告诉框架有关新颖路径的信息。

next.confg.js (next.confg.js)

Source: https://github.com/nzcodarnoc/korerorero-front-end/blob/v0.3.1/next.config.js

来源： https : //github.com/nzcodarnoc/korerorero-front-end/blob/v0.3.1/next.config.js

This does two things. Firstly, assetPrefix is a config option designed to have assets served from a CDN, but it is equally able to be a host subdirectory.

这有两件事。首先， assetPrefix是一个配置选项，旨在让CDN提供资产，但它同样可以成为主机子目录。

Secondly, adding publicRuntimeConfig makes SELF_PATH available in the browser environment. Though next.js supports .env variables out-of-the-box by reading them fromprocess.env, process is only available in the server node.js environment. Using publicRuntimeConfig exports them to the browser environment too.

其次，添加publicRuntimeConfig使SELF_PATH在浏览器环境中可用。尽管next.js通过从process.env中读取变量来支持现成的.env变量，但是process仅在服务器node.js环境中可用。使用publicRuntimeConfig它们导出到浏览器环境。

The reason for this is that occasionally a Javascript library will require the creation of a link to a server side resource, outside of the build process. For example, in creating a socket to stream audio from the users mic, to the text recognition service, a service worker is created and that worker is outside of the build. Here’s the example:

这样做的原因是，有时Javascript库需要在构建过程之外创建指向服务器端资源的链接。例如，在创建用于将音频从用户麦克风流传输到文本识别服务的套接字时，将创建服务工作程序，而该工作程序不在构建之内。这是示例：

实用程序 (utils.ts)

Source: https://github.com/nzcodarnoc/korerorero-front-end/blob/v0.3.1/src/utils.ts

来源： https : //github.com/nzcodarnoc/korerorero-front-end/blob/v0.3.1/src/utils.ts

Recognizer.js (Recognizer.js)

Source: https://github.com/nzcodarnoc/korerorero-front-end/blob/v0.3.1/src/components/Recognizer.js

来源： https : //github.com/nzcodarnoc/korerorero-front-end/blob/v0.3.1/src/components/Recognizer.js

In the examples above STATIC_PATH is set by calling getConfig() and getting the value of SELF_PATH.

在上面的例子STATIC_PATH通过调用设置getConfig()并获得的值SELF_PATH 。

To be honest, dear reader, I cannot see the advantage of renaming the variable, but me-in-the-past thought it was a good idea.

老实说，亲爱的读者，我看不到重命名变量的好处，但是过去，我认为这是个好主意。

The effect of all of this is that the app can be run from localhost/ during development, and when deployed it can be accessed from example.com/front-end.

所有这些的影响在于，该应用程序可以在开发期间从localhost/运行，并且在部署后可以从example.com/front-end访问。