Node 和 React 同构渲染架构
Node and React Isomorphic Rendering Architecture
所以我了解使用 React / Node 进行同构渲染的基础知识，但我对如何将 Apache 或 NGINX 融入我的环境感到困惑。
通常，对于客户端页面，我只提供来自 Apache 或 NGINX 的静态内容，客户端页面会对 Node 进行 AJAX 调用（通过 Apache 或 NGINX 反向代理） . Node 会提供数据，页面也会随之改变。
查看 React 的同构页面，该页面最初在 Node 服务器上呈现，更改从服务器提供给客户端。我仍然可以使用 Apache 或 NGINX 来负载平衡和反向代理我的请求吗？
例如，我将有一个 Node 实例为我的 API 服务，还有一个 Node 实例用于呈现 React 并将其提供给客户端。在此示例中，我可以负载平衡、反向代理我的调用，并从 Apache/NGINX 提供我的 .js 和 .css 包吗？在此示例中，用户将访问 www.example.com/ - 这将首先转到 Apache/NGINX，后者将反向代理对节点服务器的调用，节点服务器将呈现页面并将其提供给客户端。然后，在页面上，客户端将单击某个按钮并访问 www.example.com/api/test，这也会转到 Apache/NGINX 并反向代理到第二个 Node 实例，该实例将为数据提供服务返回给客户端。还是应该单击该按钮返回到第一个 Node 实例（进行渲染的地方），然后该 Node 实例调用第二个 Node 实例来获取数据、渲染新片段并将其返回给客户端？
基本上我想要一个同构应用程序，它具有在我的节点服务器前面安装 Apache 或 NGINX 的所有好处。这可能是 and/or 最佳实践吗？如果不是，同构应用程序的理想环境是什么，这样我仍然可以保持 Apache 或 NGINX 的所有优势作为我的 web 应用程序的入口点？
是的，应该一切正常。 React/Node 服务器只呈现 html，并且可以像任何其他 html 后端一样进行反向代理。
是的，如果您计划 运行 大规模地使用 reverse-proxy/loadbalancer 在您的服务器前是个好主意。
所以我了解使用 React / Node 进行同构渲染的基础知识，但我对如何将 Apache 或 NGINX 融入我的环境感到困惑。
通常，对于客户端页面，我只提供来自 Apache 或 NGINX 的静态内容，客户端页面会对 Node 进行 AJAX 调用（通过 Apache 或 NGINX 反向代理） . Node 会提供数据，页面也会随之改变。
查看 React 的同构页面，该页面最初在 Node 服务器上呈现，更改从服务器提供给客户端。我仍然可以使用 Apache 或 NGINX 来负载平衡和反向代理我的请求吗？
例如，我将有一个 Node 实例为我的 API 服务，还有一个 Node 实例用于呈现 React 并将其提供给客户端。在此示例中，我可以负载平衡、反向代理我的调用，并从 Apache/NGINX 提供我的 .js 和 .css 包吗？在此示例中，用户将访问 www.example.com/ - 这将首先转到 Apache/NGINX，后者将反向代理对节点服务器的调用，节点服务器将呈现页面并将其提供给客户端。然后，在页面上，客户端将单击某个按钮并访问 www.example.com/api/test，这也会转到 Apache/NGINX 并反向代理到第二个 Node 实例，该实例将为数据提供服务返回给客户端。还是应该单击该按钮返回到第一个 Node 实例（进行渲染的地方），然后该 Node 实例调用第二个 Node 实例来获取数据、渲染新片段并将其返回给客户端？
基本上我想要一个同构应用程序，它具有在我的节点服务器前面安装 Apache 或 NGINX 的所有好处。这可能是 and/or 最佳实践吗？如果不是，同构应用程序的理想环境是什么，这样我仍然可以保持 Apache 或 NGINX 的所有优势作为我的 web 应用程序的入口点？
是的，应该一切正常。 React/Node 服务器只呈现 html，并且可以像任何其他 html 后端一样进行反向代理。
是的，如果您计划 运行 大规模地使用 reverse-proxy/loadbalancer 在您的服务器前是个好主意。