使用 PHP 来做 Vue.js 的 SSR 服务端渲染

更新日期: 2018-04-09阅读: 4.4k标签: SSR


对于客户端应用来说,服务端渲染是一个热门话题。然而不幸的是,这并不是一件容易的事,尤其是对于不用 Node.js 环境开发的人来说。我发布了两个库让 php 从服务端渲染成为可能.spatie/server-side-rendering 和 spatie/laravel-server-side-rendering适配 laravel 应用。让我们一起来仔细研究一些服务端渲染的概念,权衡优缺点,然后遵循第一法则用 PHP 建立一个服务端渲染。


什么是服务端渲染

一个单页应用(通常也叫做 SPA )是一个客户端渲染的 App 。这是一个仅在浏览器端运行的应用。如果你正在使用框架,比如 reactvue.js 或者 angularJS ,客户端将从头开始渲染你的 App 。

浏览器的工作

在 SPA 被启动并准备使用之前,浏览器需要经过几个步骤。

  • 下载 JavaScript 脚本
  • 解析 JavaScript 脚本
  • 运行 JavaScript 脚本
  • 取回数据(可选,但普遍)
  • 在原本的空容器渲染应用  (首次有意义的渲染)
  • 准备完成! (可以交互啦)

用户不会看到任何有意义的内容,直到浏览器完全渲染 App(需要花费一点时间)。这会造成一个明显的延迟,直到 首次有意义的渲染 完成,从而影响了用户体验。

这就是为什么服务端渲染(一般被称作 SSR )登场的原因。SSR 在服务器预渲染初始应用状态。这里是浏览器在使用服务端渲染后需要经过的步骤:

  • 渲染来自服务端的 html (首次有意义的渲染)
  • 下载 JavaScript 脚本
  • 解析 JavaScript 脚本
  • 运行 JavaScript 脚本
  • 取回数据
  • 使已存在的 HTML 页面可交互
  • 准备完成! (可以交互啦)

由于服务器提供了 HTML 的预渲染块,因此用户无需等到一切完成后才能看到有意义的内容。注意,虽然 交互时间 仍然处于最后,但可感知的表现得到了巨大的提升。

服务端渲染的优点

服务端渲染的主要优点是可以提升用户体验。并且,如果你的网站需要应对不能执行 JavaScript 的老旧爬虫,SSR 将是必须的,这样,爬虫才能索引服务端渲染过后的页面,而不是一个空荡荡的文档。


服务端如何渲染?

记住服务端渲染并非微不足道,这一点很重要。当你的 Web 应用同时运行在浏览器和服务器,而你的 Web 应用依赖 dom 访问,那么你需要确保这些调用不会在服务端触发,因为没有 DOM api 可用。

基础设施复杂性

假设你决定了服务端渲染你的应用端程序,你如果正在阅读这篇文章,很大可能正在使用 PHP 构建应用的大部分(功能)。但是,服务端渲染的 SPA 需要运行在 Node.js 环境,所以将需要维护第二个程序。

你需要构建两个应用程序之间的桥梁,以便它们进行通信和共享数据:需要一个 API。构建无状态 API 相比于构建有状态是比较 困难的。你需要熟悉一些新概念,例如基于 JWT 或 OAUTH 的验证,CORS,REST ,添加这些到现有应用中是很重要的。

有得必有所失,我们已经建立了 SSR 以增加 Web 应用的用户体验,但 SSR 是有成本的。

服务器端渲染权衡取舍

服务器上多了一个额外的操作。一个是服务器增加了负载压力,第二个是页面响应时间也会稍微加长。 不过因为现在服务器返回了有效内容,在用户看来,第二个问题的影响不大。

大部分时候你会使用 Node.js 来渲染你的 SPA 代码。如果你的后端代码不是使用 Javascript 编写的话,新加入 Node.js 堆栈将使你的程序架构变得复杂。

为了简化基础架构的复杂度, 我们需要找到一个方法,使已有的 PHP 环境作为服务端来渲染客户端应用。


在 PHP 中渲染 JavaScript

在服务器端渲染 SPA 需要集齐以下三样东西:

  • 一个可以执行 JavaScript 的引擎
  • 一个可以在服务器上渲染应用的脚本
  • 一个可以在客户端渲染和运行应用的脚本

SSR scripts 101

下面的例子使用了 Vue.js。你如果习惯使用其它的框架(例如 React),不必担心,它们的核心思想都是类似的,一切看起来都是那么相似。

简单起见,我们使用经典的 “ Hello World ” 例子。

下面是程序的代码(没有 SSR):

// app.js
import Vue from 'vue'

new Vue({
  template: `
    <div>Hello, world!</div>
  `,

  el: '#app'
})

这短代码实例化了一个 Vue 组件,并且在一个容器(id 值为 app 的 空 div)渲染。

如果在服务端运行这点脚本,会抛出错误,因为没有 DOM 可访问,而 Vue 却尝试在一个不存在的元素里渲染应用。

重构这段脚本,使其 可以 在服务端运行。

// app.js
import Vue from 'vue'

export default () => new Vue({
  template: `
    <div>Hello, world!</div>
  `
})

// entry-client.js
import createApp from './app'

const app = createApp()

app.$mount('#app')

我们将之前的代码分成两部分。app.js 作为创建应用实例的工厂,而第二部分,即 entry-client.js,会运行在浏览器,它使用工厂创建了应用实例,并且挂载在 DOM。

现在我们可以创建一个没有 DOM 依赖性的应用程序,可以为服务端编写第二个脚本。

// entry-server.js
import createApp from './app'
import renderToString from 'vue-server-renderer/basic'

const app = createApp()

renderToString(app, (err, html) => {
  if (err) {
    throw new Error(err)
  }
  // Dispatch the HTML string to the client...
})

我们引入了相同的应用工厂,但我们使用服务端渲染的方式来渲染纯 HTML 字符串,它将包含应用初始状态的展示。

我们已经具备三个关键因素中的两个:服务端脚本和客户端脚本。现在,让我们在 PHP 上运行它吧!


执行 JavaScript

在 PHP 运行 JavaScript,想到的第一个选择是 V8Js。V8Js 是嵌入在 PHP 扩展的 V8 引擎,它允许我们执行 JavaScript。

使用 V8Js 执行脚本非常直接。我们可以用 PHP 中的输出缓冲和 JavaScript 中的 print 来捕获结果。

$v8 = new V8Js();

ob_start();

// $script 包含了我们想执行的脚本内容

$v8->executeString($script);

echo ob_get_contents();
print('<div>Hello, world!</div>')

这种方法的缺点是需要第三方 PHP 扩展,而扩展可能很难或者不能在你的系统上安装,所以如果有其他(不需要安装扩展的)方法,它会更好的选择。

这个不一样的方法就是使用 Node.js 运行 JavaScript。我们可以开启一个 Node 进程,它负责运行脚本并且捕获输出。
Symfony 的 Process 组件就是我们想要的。

use Symfony\Component\Process\Process;

// $nodePath 是可执行的 Node.js 的路径
// $scriptPath 是想要执行的 JavaScript 脚本的路径

new Process([$nodePath, $scriptPath]);

echo $process->mustRun()->getOutput();
console.log('<div>Hello, world!</div>')

注意,(打印)在 Node 中是调用 console.log 而不是 print 。


让我们一起来实现它吧!

spatie/server-side-rendering 包的其中一个关键理念是 引擎 接口。引擎就是上述 JavaScript 执行的一个抽象概念。

namespace Spatie\Ssr;

/**
 * 创建引擎接口。
 */
interface Engine
{
    public function run(string $script): string;
    public function getDispatchHandler(): string;
}

run 方法预期一个脚本的输入 (脚本 内容,不是一条路径),并且返回执行结果。 getDispatchHandler 允许引擎声明它预期脚本如何展示发布。例如 V8 中的print 方法,或是 Node 中的 console.log 。

V8Js 引擎实现起来并不是很花俏。它更类似于我们上述理念的验证,带有一些附加的错误处理机制。

namespace Spatie\Ssr\Engines;

use V8Js;
use V8JsException;
use Spatie\Ssr\Engine;
use Spatie\Ssr\Exceptions\EngineError;

/**
 * 创建一个 V8 类来实现引擎接口类 Engine 。
 */
class V8 implements Engine。
{
    /** @var \V8Js */
    protected $v8;

    public function __construct(V8Js $v8)
    {
        $this->v8 = $v8;
    }

    /**
     * 打开缓冲区。
     * 返回缓冲区存储v8的脚本处理结果。
     */
    public function run(string $script): string
    {
        try {
            ob_start();

            $this->v8->executeString($script);

            return ob_get_contents();
        } catch (V8JsException $exception) {
            throw EngineError::withException($exception);
        } finally {
            ob_end_clean();
        }
    }

    public function getDispatchHandler(): string
    {
        return 'print';
    }
}

注意这里我们将 V8JsException 重新抛出作为我们的 EngineError。 这样我们就可以在任何的引擎视线中捕捉相同的异常。

Node 引擎会更加复杂一点。不像 V8Js,Node 需要 文件 去执行,而不是脚本内容。在执行一个服务端脚本前,它需要被保存到一个临时的路径。

namespace Spatie\Ssr\Engines;

use Spatie\Ssr\Engine;
use Spatie\Ssr\Exceptions\EngineError;
use Symfony\Component\Process\Process;
use Symfony\Component\Process\Exception\ProcessFailedException;

/**
 * 创建一个 Node 类来实现引擎接口类 Engine 。
 */
class Node implements Engine
{
    /** @var string */
    protected $nodePath;

    /** @var string */
    protected $tempPath;

    public function __construct(string $nodePath, string $tempPath)
    {
        $this->nodePath = $nodePath;
        $this->tempPath = $tempPath;
    }

    public function run(string $script): string
    {
        // 生成一个随机的、独一无二的临时文件路径。
        $tempFilePath = $this->createTempFilePath();

        // 在临时文件中写进脚本内容。
        file_put_contents($tempFilePath, $script);

        // 创建进程执行临时文件。
        $process = new Process([$this->nodePath, $tempFilePath]);

        try {
            return substr($process->mustRun()->getOutput(), 0, -1);
        } catch (ProcessFailedException $exception) {
            throw EngineError::withException($exception);
        } finally {
            unlink($tempFilePath);
        }
    }

    public function getDispatchHandler(): string
    {
        return 'console.log';
    }

    protected function createTempFilePath(): string
    {
        return $this->tempPath.'/'.md5(time()).'.js';
    }
}

除了临时路径步骤之外,实现方法看起来也是相当直截了当。

我们已经创建好了 Engine 接口,接下来需要编写渲染的类。以下的渲染类来自于 spatie/server-side-rendering 扩展包,是一个最基本的渲染类的结构。

渲染类唯一的依赖是 Engine 接口的实现:

class Renderer
{
    public function __construct(Engine $engine)
    {
        $this->engine = $engine;
    }
}

渲染方法 render 里将会处理渲染部分的逻辑,想要执行一个 JavaScript 脚本文件,需要以下两个元素:

  • 我们的应用脚本文件;
  • 一个用来获取解析产生的 HTML 的分发方法;

一个简单的 render 如下:

class Renderer
{
    public function render(string $entry): string
    {
        $serverScript = implode(';', [
            "var dispatch = {$this->engine->getDispatchHandler()}",
            file_get_contents($entry),
        ]);

        return $this->engine->run($serverScript);
    }
}

此方法接受  entry-server.js 文件路径作为参数。

我们需要将解析前的 HTML 从脚本中分发到 PHP 环境中。dispatch 方法返回 Engine 类里的 getDispatchHandler 方法,dispatch 需要在服务器脚本加载前运行。

还记得我们的服务器端入口脚本吗?接下来我们在此脚本中调用我们的  dispatch 方法:

// entry-server.js
import app from './app'
import renderToString from 'vue-server-renderer/basic'

renderToString(app, (err, html) => {
  if (err) {
    throw new Error(err)
  }
  dispatch(html)
})

Vue 的应用脚本无需特殊处理,只需要使用  file_get_contents 方法读取文件即可。

我们已经成功创建了一个 PHP 的 SSR 。spatie/server-side-rendering 中的完整渲染器 Renderer 跟我们实现有点不一样,他们拥有更高的容错能力,和更加丰富的功能如有一套 PHP 和 JavaScript 共享数据的机制。如果你感兴趣的话,建议你阅读下源码 server-side-rendering 代码库 。


三思而后行

我们弄清楚了服务器端渲染的利和弊,知道 SSR 会增加应用程序架构和基础结构的复杂度。如果服务器端渲染不能为你的业务提供任何价值,那么你可能不应该首先考虑他。

如果你 确实 想开始使用服务器端渲染,请先阅读应用程序的架构。大多数 JavaScript 框架都有关于 SSR 的深入指南。Vue.js 甚至有一个专门的 SSR 文档网站,解释了诸如数据获取和管理用于服务器端渲染的应用程序方面的坑。

如果可能,请使用经过实战检验的解决方案

有许多经过实战检验的解决方案,能提供很好的 SSR 开发体验。比如,如果你在构建 React 应用,可以使用 Next.js,或者你更青睐于 Vue 则可用 Nuxt.js,这些都是很引人注目的项目。

还不够?尝试 PHP 服务端渲染

你仅能以有限的资源来管理基础架构上的复杂性。你想将服务端渲染作为大型 PHP 应用中的一部分。你不想构建和维护无状态的 API。 如果这些原因和你的情况吻合,那么使用 PHP 进行服务端渲染将会是个不错方案。

我已经发布两个库来支持 PHP 的服务端 JavaScript 渲染:  spatie/server-side-rendering  和专为 Laravel 应用打造的 spatie/laravel-server-side-rendering  。Laravel 定制版在 Laravel 应用中近乎 0 配置即可投入使用,通用版需要根据运行环境做一些设置调整。当然,详细内容可以参考软件包自述文件。

如果你仅是想体验,从 spatie/laravel-server-side-rendering-examples  检出项目并参考指南进行安装。

如果你考虑服务端渲染,我希望这类软件包可以帮到你,并期待通过 Github 做进一步问题交流和反馈!

更多现代化 PHP 知识,请前往 Laravel / PHP 知识社区

原文:https://www.cnblogs.com/summerblue/p/8707643.html 

 

链接: https://fly63.com/article/detial/604

React 中同构(SSR)原理脉络梳理

随着越来越多新型前端框架的推出,SSR 这个概念在前端开发领域的流行度越来越高,也有越来越多的项目采用这种技术方案进行了实现。SSR 产生的背景是什么?适用的场景是什么?实现的原理又是什么?

vue-ssr之nuxt.js的插件使用

有时候,我们会有这样的需求,在项目的前端页面中需要使用一个swiper插件,来实现图片轮播,但是nuxt是在服务端进行编译的,那么问题来了,我们如何像在vue中那样使用第三方模块,封装轮播公用组件呢?答案是:使用nuxt到插件功能。

手把教你搭建SSR(vue/vue-cli + express)

最近简单的研究了一下SSR,对SSR已经有了一个简单的认知,主要应用于单页面应用,Nuxt是SSR很不错的框架。也有过调研,简单的用了一下,感觉还是很不错。但是还是想知道若不依赖于框架又应该如果处理SSR,研究一下做个笔记。

基于Vue-SSR优化方案归纳总结

Vue-SSR相信大家都不陌生,与传统 SPA 相比,服务器端渲染 (SSR) 能够具备更好的SEO,方便搜索引擎爬虫抓取工具可以直接查看完全渲染的页面,除此之外,SSR能够在更短的时间内渲染出页面内容,通过在服务端填充数据吐出到客户端的方式,让用户有更好的用户体验。

一文带你搞懂 SSR

Server-side rendering (SSR)是应用程序通过在服务器上显示网页而不是在浏览器中渲染的能力。服务器端向客户端发送一个完全渲染的页面(准确来说是仅仅是 HTML 页面)

React SSR 之为什么要进行限流

当对 React 应用进行页面加载或 SEO 优化时,我们一般绕不开 React SSR。但 React SSR 毕竟涉及到了服务端,有很多服务端特有的问题需要考虑,而限流就是其中之一。

React SSR 之限流

当对 React 应用进行页面加载或 SEO 优化时,我们一般绕不开 React SSR。但 React SSR 毕竟涉及到了服务端,有很多服务端特有的问题需要考虑,而限流就是其中之一。

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!