Gatsby（Static/Dynamic + GraphQL）

Front End Framework with the speed to delight

The static dynamic site generator for dynamic web developers

官方网站： https://www.gatsbyjs.com

Data source

• GraphQL： https://www.gatsbyjs.com/plugins/gatsby-source-graphql/
• Without（RESTful API）： https://www.gatsbyjs.com/docs/how-to/querying-data/using-gatsby-without-graphql/
• 数据库： https://www.gatsbyjs.com/docs/how-to/sourcing-data/sourcing-from-databases/
• 自定义 Source 插件： https://www.gatsbyjs.com/docs/how-to/plugins-and-themes/creating-a-source-plugin/

Deploy

Dynamic （SSR）

即 SSR，服务器端渲染。

优势

• SEO 友好（可能。至于究竟好不好，还是看代码）
• 路由友好（动态路由匹配，渲染内容，实际上也还是 SEO 友好）

本地前端开发环境，现在基本上都是 SSR 的。方便问题排查，性能调优。到了服务器上也是一样。

劣势

• 并发性能瓶颈
• 首屏加载（慢，需要额外做更多处理）
• CDN 不友好

相较于纯静态页面，动态页面性能上毫无优势可言。即便与动态技术相比（如 PHP之类的编程语言、使用 HTML 模板语言渲染等），也是差距极大。因为需要把模板渲染出 HTML 还没完，还需要构建虚拟 Dom。

很多人说 SSR 的优点有首屏渲染快，但实际上纯静态网站做首屏优化更容易，而且能够更快。

同时还有很多人说 SSR 另一个优点是可以缓存；那比较起来，纯静态页面本身就是缓存的产物。

适用场景

主要满足的业务场景：

• 开发/测试环境
• 频繁变化的动态内容（核心场景诉求）
• 对 SEO 要求高的网站（但注意一下，纯静态也可以做得 SEO 友好）

限制要求：

• 流量小
• 不计成本（服务器性能高）

refs

• 从 3.9 版本升级 React 18，更换新的 SSR 架构：https://www.gatsbyjs.com/docs/reference/release-notes/v3.9/#react-18—new-suspense-ssr-architecture
• 从 3.5 版本开始支持：https://www.gatsbyjs.com/docs/reference/release-notes/v3.5/#new-ssr-in-develop-overlay
• React 18 新 SSR 架构解决了什么问题： https://jigsawye.com/2021/06/10/react-18-new-ssr-architecture

Static

自前后端分离后，无论 SPA 还是传统的前端应用，实际上均为纯静态的。

优势

• CDN 可完全托管，成本低、访问快、加载快
• 不用考虑服务器安全性问题、并发性能问题等诸多问题

劣势

• 部署（如果是用了 CDN，还需要清理，还需要额外配置缓存规则）
• SPA 应用的话对于 SEO 不够友好
• 纯静态应用的话又对于频繁变更的内容不友好（每次都要编译，部署）

除了一些已知的问题，纯静态部署对比其他方式基本都是优势。

适用场景

各类不会频繁内容修改的网站（或者只是改改错别字，删除文章，没有实时变化数据的），又有一些 SEO 诉求的。比如：

• 企业网站
• 产品官网
• 个人/团队博客

限制要求：

• 对于内容（文章）数量巨大的不适用，因为修改连接等操作即便是增量部署也会很多

Static （Mixin）

纯静态部署，加载动态内容。

适用场景

• 所有需要先登录鉴权才能访问的业务系统（没有 SEO 要求）

Best Practice

由于我们目前没有 CMS 内容管理的需求，大部分业务是后台关系系统的前端交互。通过上述对比，总结下来为：

• SSR 用作本地开发、测试环境中问题排查及性能调优
• 最终部署的产物为 Static （Mixin）