作爲php模板渲染服務reactjs node.js是一個好主意嗎？

我的網站是用PHP編寫的。 Node.js也爲socket.io設置。我一直在考慮使用Reactjs進行服務器端渲染，以便重用視圖。計劃使用v8js擴展，但後來我碰到this article來談論兩個可能的解決方案：作爲php模板渲染服務reactjs node.js是一個好主意嗎？

1.使用v8js擴展和應對-PHP-V8Js從PHP

2.發送數據的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擴展，這不是一個選項。就我個人而言，我不會走這條路。安裝依賴關係很麻煩，依賴關係管理很棘手，並且沒有太多的資源可以指導你一路走來。 在此外，如果您想要重新使用他們，則需要考慮您的javascript 版本不應該與反應捆綁在一起。

你能告訴我他的意思是「javascript builds無法與反應捆綁」嗎？我一直在考慮使用v8js + React-PHP-V8Js，所以我想了解它的一些缺點。另外，你更喜歡第二種方法（node.js作爲模板渲染服務）嗎？我已經運行了node.js，所以這似乎是一個很好的建議。

來源

2016-07-08 RedGiant

這是一個意見問題，所以你得到的任何答案將是一個意見。

我會說不，這不是一個好主意，並解釋我的推理。

每個軟件項目的複雜性都可以用所使用的流行語的數量來粗略衡量。也就是說，「由AWS Lambda服務支持的高可用性，多語言，React網站」聽起來天生就有毛病。每一個流行詞都是以前流行語的成果。您建議使用ReactJS構建「一個使用PHP進行服務器端渲染的站點，並使用底層節點V8JS渲染......」，並且在遇到問題域之前就已經耗盡了複雜性。

你會遇到React有一個完全不同的渲染模型的問題。你會遇到緩存問題。你會遇到系統管理員問題。

不要這樣做。

來源

2016-07-15 22:57:25

我認爲第二個選項「運行模板引擎作爲服務」是一個更好的選擇，因爲它具有更少的複雜性和更少的依賴性。

我認爲服務器端渲染是一個有趣的想法，它有很多很大的好處。

服務器的性能比用戶的許多不同設備配置更具可預測性。所以這裏有一點思考你的應用的目標受衆是什麼。（如果很多用戶使用蹩腳手機然後加點服務器端渲染）
感知性能的增加。用戶正在避開空白頁面並加載微調器。（感知性能 - 因爲用戶仍然必須等待附加的事件處理程序）
您可以將您的網站提供給通常不具備JavaScript功能的抓取工具。
我認爲正確執行服務器端渲染可以提供更少的複雜性和更少的維護開銷。但這對於更大的團隊來說更有益處。 對於構造和抽象代碼工作的單個開發人員來說，將需要比分離客戶端和服務器視圖花費許多時間。

因此，總之，我不會把研究噸到它之前做到這一點，我的建議是「保持簡單」。對於每一個喜悅，都有一定的代價。

有些問題需要克服：

要正確呈現模板服務器端和客戶端需要訪問同一個應用程序的狀態。（查Redux https://github.com/reactjs/redux）

真正的網絡應用程序通常需要與服務器交互並從中加載數據。所以你如何用當前的設置來處理這個問題。

您可能在視圖中執行異步操作，而服務器端呈現是同步的。

額外的安全隱患。

來源

2016-07-16 02:48:50

從長遠來看，第二種方法在我看來是一個比較好的方法，與較短期項目中的第一個方案相比，它需要更多的變量和更多的處理來處理變量和處理JavaScript。如果您使用第二個選項，您將有更少的維護和更容易的時間解決您可能遇到的錯誤。在我看來，如果它只是PHP上的PHP而不是處理這些響應的JavaScript，也更容易整合。

來源

2016-07-17 06:49:23 BlakeAyrl

作爲php模板渲染服務reactjs node.js是一個好主意嗎？

回答

相關問題