是node.js与reactjs作为PHP模板渲染服务一个好主意？
我的网站是用PHP编写的。 Node.js也是为socket.io设置的。 我一直在考虑使用Reactjs进行服务器端渲染，以便重用视图。 计划使用v8js扩展，但是后来我遇到了这篇文章谈论两个可能的解决scheme：
1.使用v8js扩展和React-PHP-V8Js
2.从php发送数据到node.js来渲染视图，例如：
的node.js
require("babel/register"); var React = require('react'); var express = require('express'); var path = require('path'); var bodyParser = require('body-parser'); var app = express(); app.use(bodyParser.json()); app.use('/', function(req, res) { try { var view = path.resolve('./views/' + req.query.module); var component = require(view); var props = req.body || null; res.status(200).send( React.renderToString( React.createElement(component, props) ) ); } catch (err) { res.status(500).send(err.message); } }); PHP
use GuzzleHttp\Client; $app->get('/{name:.*?}', function($name) use ($app) { $client = new Client(['base_url' => 'http://localhost:3000']); $response = $client->post('/', [ 'json' => ['name' => ucfirst($name ?: 'World')], 'query' => ['module' => 'hello'], ]); $contents = $response->getBody()->getContents(); return response($contents, 200); });
作者说他更喜欢第二种方法，因为第一种：
除非您愿意在生产机器上安装（和更新）libv8和V8Js PECL扩展，否则这不是一种select。 就我个人而言，我不会走这条路。 安装依赖关系比较麻烦，依赖关系pipe理比较棘手，并且没有太多的资源可以指导你。 另外，如果你想重新使用它们，你需要考虑到你的javascript版本不应该与反应捆绑在一起 。
你能告诉我他的意思是“JavaScript构build不能与反应捆绑”吗？ 我一直在考虑使用v8js + React-PHP-V8Js所以我想了解它的一些缺点。 另外，你更喜欢第二种方法（node.js作为模板渲染服务）？ 我已经运行node.js所以这似乎是一个很好的build议。
这是一个意见问题，所以你得到的答案将是一个意见。
我会说不，这不是一个好主意，并解释我的推理。
每个软件项目的复杂性都可以用所使用的stream行语的数量来粗略衡量。 也就是说，“一个由AWS Lambda服务支持的高可用性，多语言，React网站”听起来天生就有毛病。 每一个stream行词都是以前的stream行语。 您正在build议使用ReactJS构build“使用PHP进行服务器端渲染并使用底层节点V8JS渲染的站点”，并且您在遇到问题域之前就已经耗尽了复杂性。
你会碰到与React有一个完全不同的渲染模型的问题。 您将遇到caching问题。 你会打系统pipe理员问题。
不要这样做。
我认为第二个选项“运行模板引擎作为服务”是一个更好的select，因为它具有更less的复杂性和更less的依赖性。
我认为服务器端渲染是一个有趣的想法，它有很多很大的好处。
-
服务器的性能比用户的许多不同设备configuration更具可预测性。 所以这里有一个小小的想法是什么是你的应用程序的目标受众。 （如果很多用户使用蹩脚的移动，那么服务器端渲染加分）
-
感知性能的提高。 用户正在避免空白页面和加载微调框。 （感知性能 – 因为用户仍然必须等待附加的事件处理程序）
-
您可以将您的networking提供给通常不具有JavaScriptfunction的抓取工具。
-
我认为正确执行服务器端渲染可以提供更less的复杂性和更less的维护开销。 但是对于更大的团队来说，这是更多的好处。 对于构build和抽象代码工作的单个开发人员来说，要花费比分离客户端和服务器视图更多的时间。
所以，总之，在做大量的研究之前，我不会这样做，我的build议是“保持简单”。 对于每一个喜悦，都有一定的代价。
需要克服的一些问题：
要正确呈现模板服务器端，客户端将需要访问相同的应用程序状态。 （查Redux https://github.com/reactjs/redux ）
真正的networking应用程序通常需要与服务器交互并从中加载数据。 所以你如何用当前的设置来处理这个问题。
您可能在视图中执行asynchronous操作，而服务器端呈现是同步的。
额外的安全影响。
第二个select是长期看来比较好的主意，相比较短期项目中的第一个项目需要更多的variables和更多的处理来处理variables和处理JavaScript。 如果您使用第二个选项，将会减less维护次数，并且更轻松地解决可能遇到的错误。 在我看来，如果它只是PHP上的PHP而不是处理这些响应的JavaScript，也更容易整合。