同构or服务端渲染

同构

同构（isomorph）这个概念应该来源于数学。同构是在数学对象之间定义的一类映射，若两个数学结构之间存在同构映射，那么这两个结构叫做“是同构的”。如果两个结构是同构的，那么其上的对象会有相似的属性和操作，对某个结构成立的命题在另一个结构上也就成立。

在大前端，同构JavaScript应用指的是，用JavaScript编写的应用能够同时运行于客户端和服务器。因此，只需编写一次代码，在服务器上执行它来渲染静态页面，同时执行于客户端以允许快速的交互。

大前端演变的过程：

纯后端渲染 -> 单页面应用（前端渲染和交互） -> 同构（后端渲染和前端交互）

现在，同构和服务端渲染（server side render， SSR）基本是同义词。

SSR的优缺点

优点：

• 更好的SEO
• 更快的页面呈现速度

缺点：

• 更复杂的开发，开发的代码需要兼容前后端的runtime
• 更复杂的构建和部署
• 加重服务器负载

同构会不会使前后端的代码耦合在一起？答案是不会。同构只是同构SPA代码，提供API的后台代码完全可以独立成一个项目，可以和同构代码一起部署，也可以分开部署。分开部署的缺点是会多一次http请求，一个客户端请求会先请求同构的后端代码，而同构的后端代码又会请求提供API的应用来获取渲染需要的数据。如果同构的后端代码和供API的代码部署在同一台服务器，多出来的这一次请求基本不会影响性能。也可以一起部署，比如提供API的应用是用node编写的，只用把同构的后端代码的render部分插入到提供API的应用的listen部分就好了。

相关框架

基于React的SSR框架Next.js现在有19k的star，发展的比较好。而基于Vue的SSR框架Nuxt.js只有200多个star，比较惨淡。

看了一下Nuxt.js，写了简单的demo。Nuxt.js其实做了很多工作，主要是在vue.js的内核外又包了一层SSR相关的东西。个人觉得主要的问题有两个。第一是把现有的使用vue的项目迁移到Nuxt.js会很麻烦；第二是Nuxt.js把很多配置（比如webpack的配置）都封装起来了，极大地简化了项目的配置，但是带来的问题是，当项目需要非大众化的配置时，根本就无从下手，因为找不到对应的配置文件。

除了Nuxt.js，vue有一个插件vue-server-renderer来实现SSR。

vue-server-renderer

一个简单的项目文件结构：

├──src
│   ├── components
│   │   ├── Foo.vue
│   │   ├── Bar.vue
│   │   └── Baz.vue
│   ├── App.vue
│   ├── app.js # universal entry
│   ├── entry-client.js # runs in browser only
│   ├── entry-server.js # runs on server only
│   └── index.template.html
├──server.js

app.js是前后端共同的入口，一般返回vue实例的工厂函数。不能像SPA那样直接创建vue实例，因为直接创建的vue实例在服务端会被所有请求复用，从而造成状态污染。

import Vue from 'vue'
import App from './App.vue'

export function createApp () {
  const app = new Vue({
    render: h => h(App)
  })
  return { app }
}

entry-client.js是浏览器端的入口，创建vue实例，并挂载到DOM上。

import { createApp } from './app'

const { app } = createApp()

app.$mount('#app')

entry-server.js主要export一个供服务端的renderer使用的函数。

import { createApp } from './app'

export default context => {
  const { app } = createApp()
  return app
}

注意上面的import并不能在服务端运行，所以要用webpack进行打包。

index.template.html是首页渲染的模板文件，服务端渲染app得到的页面会替换掉<!–vue-