为什么更多的开发人员应该转向盖茨比

Gatsby框架值得您花时间学习，本文将为您提供其他地方不存在的答案。

作为顶级的静态网站生成器之一，盖茨比自去年以来获得了巨大的发展动力。 根据最近的统计图表显示，每周平均下载量达到20万左右。 它的口号吸引了许多Web开发人员：幸运地建立了快速的网站和应用程序 。 乍一看，开始似乎很容易，但是当您深入研究时，并非如此。

为什么选择盖茨比

7个月前，我正在寻找一个构建新的电子学习产品的Web开发框架，理想的候选人应该满足以下技术要求：

*易于上手

*没有数据库依赖

* ReactJS作为前端

* markdown文件作为内容源

*跑步时表现出色

*定制开发中的可扩展性

*降低部署成本

*后端无需内容编辑器

所有这些条件共同指向一个最终的解决方案：一个静态CMS，然后我找到了StaticGen。 在前5个框架中，Jekyll，Hugo和Hexo对我来说并不陌生。 他们都使用markdown文件作为内容源，但不使用ReactJS技术堆栈。 默认情况下，第一个Next.js不支持将markdown文件渲染为html页面。 最后，我选择盖茨比作为我的最终开发平台，因为它几乎可以满足我的所有要求。

如何设计项目结构

我们都知道如何使用create-react-app创建 ReactJS应用程序框架。 Gatsby还具有其cli工具Gatsby，可以完成一些任务，例如项目创建，启动开发服务器，构建项目以进行生产部署等。

$ gatsby新的my-gatsby-site创建的典型gatsby站点结构可能是这样的：

当您使用ReactJS将其视为SSR（服务器端渲染）框架时，它与Next.js非常相似。 但事实是两者完全不同。 实际上，Gatsby不会在收到请求时呈现页面，而是在构建时使用渲染方法来输出在构建阶段已经转换的静态html内容。 这两个框架之间的另一个区别是：

Gatsby使用markdown，json，csv，yaml文件，甚至数据库作为内容源。 与GraphQL结合使用，这些内容将映射到模板组件，然后呈现到静态Web应用程序中。

这就是Gatsby在自然界中的工作方式，它更像是一个引擎，利用各种插件将不同的数据源转换为可以通过GraphQL查询获取的统一数据格式，开发人员只需编写模板页面和GraphQL语句即可显示动态内容。

然后，回到我们的项目结构，我们如何重新组织项目，以使Gatsby可以将内容文件呈现给浏览器？ 这是使Gatsby在其他框架中独树一帜的神奇部分 。

以第一个Gatsby官方启动程序项目gatsby-starter-blog为例，我们使用gatsby new命令将gatsby-starter-blog克隆到my-blog-starter目录中：

• ＃使用Blog Starter创建一个新的Gatsby网站
• $ gatsby新的my-blog-starter https://github.com/gatsbyjs/gatsby-starter-blog

新创建的my-blog-starter项目的目录结构如下：

顶部的红色矩形勾勒出内容目录，其中包含markdown格式（.md）的博客文章内容和文章中引用的图像。 这是先前my-gatsby-site结构中未包含的附加目录。 此外， templates目录也是一个新目录，其中包含发布模板组件，该组件负责通过GraphQL将markdown文件内容提取到ReactJS组件。

在Gatsby项目中，将内容目录放在项目根目录中以及在src目录下的模板目录中都是一个好习惯。

规划项目结构的其他良好做法可能包括：将hooks和style目录放在src目录下，hooks包含所有hook组件，style包含所有与模板和页面组件分开的css模块文件。 我首选的src结构可能是这样的：

官方的盖茨比项目结构文件在这里 。

Gatsby开发人员工作流程看起来如何

在my-blog-starter项目中，我们看到了内容.md文件和blog-post.js模板。 那么，组合任务由谁负责，其工作原理是什么？ 答案在gatsby-node.js中 。

基本上，gatsby-node.js文件充当组装工厂，它首先将内容源转换为节点模型，然后使用源自节点对象的模板和上下文参数创建页面组件。

关于Gatsby构建生命周期的官方文档在这里 ，同时也必须阅读Gatsby Internals的幕后花絮 ，为开发人员提供对内部工作机制的详尽描述。

在这里，我想将过程总结为一个简单的图形：

在开发Gatsby应用程序时，我们必须首先了解2个重要的配置文件： gatsby-config.js和gatsby-node.js 。 一种用于网站元数据定义和插件参考，另一种用于构建过程回调函数的实现。

这是与传统Web开发的主要区别。 在传统的Web开发工作流程中，我们启动Web服务器，读取与应用程序相关的配置（例如端口号，数据库访问帐户和其他全局参数），然后将服务公开给客户端请求。 但是在盖茨比，我们不在服务器中运行服务，而是在构建时通过插件和回调函数创建内容，然后将其交付给CDN。

简而言之，Gatsby工作流程可以在以下图中概述：

然后，我们的例行迭代开发工作可能会从准备工作开始，准备工作可能包括编写配置文件和页面模板以及内容源，然后在gatsby-node.js中实现回调函数，最后运行$ gasby开发以查看结果。

在这些文件中，模板组件开发将花费大量时间。 您需要实现UI，交互式逻辑，在graphql资源管理器中编写GraphQL语句以测试要显示的数据，然后复制这些查询语句并粘贴到模板组件中以供以后构建使用。 模板组件就像连接数据源和UI层的胶水。

等待，如果数据不在文件中而是在DB或第三部分系统中怎么办？ 答案是使用现有的Gatsby插件或开发自己的Gatsby插件。

因此，要使用盖茨比，您必须以盖茨比的方式思考，就像上面的图所描述的那样：

• 使用插件获取源数据并将其转换为Gatsby已知数据模型
• 使用GraphQL从Gatsby查询UI /模板所需的数据
• 使用构建挂钩 （回调函数）从模板组件生成html内容

对前端开发人员有什么变化

Web框架层出不穷，但是优秀的框架是如此罕见。 在众多的JAMstack解决方案中，我相信盖茨比是最独特和创新的。 盖茨比（Gatsby）声称可以建立快速的用户体验网站， 官方文件中的 Lighthouse测试证明了他们的说法。 他们是如何做到的？

产品背后的思想和他们遵循的架构模式可确保其高性能。

对于普通的开发人员来说，当您要开发原型Web应用程序，为用户提供出色的用户体验而又不费吹灰之力进行一点点调整时，这可能意味着很多，此外，您没有太多钱购买数据库服务，并且网络服务器。

以我的第一个盖茨比项目UltronEle为例，我花了将近3个月（ 60〜70个工作日）的开发时间来实现功能丰富的电子学习产品的第一个版本。 我所有的开发时间都花在了业务逻辑和交互式逻辑实现上，无需处理数据库，无需在发布环境中部署服务器。 这使我的产品非常轻便且具有成本效益。

如果没有Gatsby框架，我怀疑我的产品是否会很快诞生。 尽管盖茨比（Gatsby）的最初勘探阶段有些混乱，但是整个开发经验是如此出色。

盖茨比的流行可能预示着更好的互联网，下一代互联网技术，高速显示，出色的用户体验，轻便的部署，较低的开发和使用成本。 这一变化将为Web开发人员和IT服务部门带来大量的潜在机会。

说服客户使用的最佳做法是什么

从市场营销的角度来看，如何将您的Gatsby解决方案出售给最适合的客户可能是最重要的问题。 该主题有几篇文章，在如何与客户和您的团队讨论盖茨比以及如何 识别盖茨比何时适合您的客户方面进行了讨论 ，以及盖茨比优势说明在其官方网站的一页中 。

互联网世界本质上由各种内容，文本，图像，音乐，视频组成……为了突破这些媒体内容以及Web资源html，javascript，css的发行界限，Gatsby旨在利用最先进的Web技术和最智能的设计模式，还引用了其他CMS框架的良好做法： 主题化 ，使其更具适应性，可重用性，可定制性。 然后，当您面对潜在客户时，如何说服愿意投资这样的技术升级，承担系统过渡风险并相信投资回报的客户？

除了那些“如何做”之外，我还总结了以下观点，以提高盖茨比在客户业务中的采用率：

• *通过插件提取来利用旧系统内容或数据
• *通过盖茨比方法解决性能瓶颈问题
• *从内部项目开始，次要功能单元
• *介绍基于ReactJS堆栈的开发团队
• *逐步采用和迁移
• *针对想要使用云服务并降低IT基础架构成本的客户

这是我目前可以想到的关于将传统Web系统迁移到Gatsby的简短建议列表。 随着我参与的项目越来越多，我相信此列表将继续增长。

网络技术以乐趣和效率不断发展，这就是盖茨比（Gatsby）来的原因，让我们明确一点，并与盖茨比（Gatsby）合作过上更好的生活。 在以下教程中，我将探索有关盖茨比的更多细节，敬请期待。

From: https://hackernoon.com/thinking-in-gatsby-way-series-overview-to-build-a-static-web-application-ux4f32bc