一竞技·(中国)官网

日期：2022-04-14 15:31:17 访问量： 0 次

我是使用drupal的内置模板构建网站，还是使用drupal的解耦与 JavaScript 框架相结合的方法构建网站好一点呢?

内容管理创新的步伐一直在加快——这是由于内容管理系统需要支持的频道数量(web、移动、社交、聊天)以及传统web频道需要JavaScript的支持所推动的，因此一竞技看到了headless或decoupled架构的出现。

已经从社区的各个角落采用了解耦drupal，为了应对解耦的趋势，我在2016年至2018年分别为架构师和开发人员撰写了如何解耦drupal的博文。在我上一篇文章的这段时间里，周围的环境发生了变化，drupal的web服务变得更好了，新的范例——静态站点生成器和JAMstack正在出现。

该更新我2019年的建议了，就如我去年所做的事情一样，让一竞技从2019年的流程图开始吧!(还有一个用文字描述的可访问的流程图)

Drupal解耦的不同方法

我想重新讨论一些已经建立的Drupal解耦方法，并讨论正在被越来越多的人采用的新模式。正如我以前所写的，从解耦的角度来看Drupal体系结构的三种常见的方法是传统的(或耦合的)、逐步解耦的和完全解耦的。由于需求的不同，Drupal存在不同的解耦风格。

在传统Drupal中，Drupal通常的所有职责都保持不变，因为Drupal是一个整体系统，因此对表示层和数据层保持完全的控制。对于需要完全控制页面上的视觉元素，并访问就地编辑和布局管理等功能的编辑人员来说，传统Drupal仍然是一个很好的选择。一竞技一直都知道Drupal。所以大多数新的内容管理项目仍然是这样构建的。

有时候，JavaScript需要提供高度交互的用户体验。在这种情况下，需要一种解耦的方法。在逐步解耦的Drupal中，JavaScript框架是在现有Drupal前端之上进行分层的。这个JavaScript可能只负责在页面上呈现单个块或组件，也可能只负责呈现页面主体中的所有内容。专用于JavaScript的页面越少，编辑器就越能通过Drupal的管理功能控制页面。

到今年为止，完全解耦Drupal是一种单独的解耦Drupal体系结构类别，它反映了表示层和CMS所有方面之间的完全分离。在这个场景中，CMS成为数据提供者，带有服务器端呈现的JavaScript应用程序负责所有呈现和标记，并通过web服务api与Drupal通信。虽然像就地编辑和布局管理这样的关键功能是不可用的，但是完全解耦的Drupal对于那些想要更好地控制前端，并且已经在Angular、React和Vue等框架中构建了应用程序的开发人员很有吸引力。

在过去的一年中，由于JavaScript开发的复杂性不断增加，完全解耦的Drupal已经发展成两种不同的模式。所谓的JAMstack (JavaScript，API，Markup)引入了一种新方法:完全解耦静态站点。静态站点提高了开发人员的效率性、安全性并降低了复杂性。像Gatsby这样的静态站点生成器将从Drupal检索内容，生成静态站点，通常通过专门的云提供商(如Netlify)将该静态站点部署到CDN上。

你打算建造什么?

和往常一样，关键的问题是您试图构建什么。以下是建筑师在2019年探索解耦Drupal的新建议:

1. 如果您打算构建一个独立的网站或web应用程序，那么选择非耦合Drupal可能是正确的选择，也可能不是，这取决于开发人员和编辑人员的评估。

2. 如果您的目的是构建多个web体验(网站或web应用程序)，那么您可以使用一个解耦的Drupal实例(没有自己面向公共前端的内容存储库)，或者(同时作为内容存储库的传统网站)。根据应用程序的动态性，您可以为高度交互的应用程序选择JavaScript框架，也可以为大多数静态网站选择静态站点生成器。

3. 如果您的意图是构建多个非web体验(本机移动或物联网应用程序)，那么您可以利用解耦的Drupal来公开web服务api，并将Drupal站点作为内容存储库使用，而不需要它自己面向公共的前端。

Drupal之所以如此强大，是因为它支持用例广泛。以及公认的标准，如JSON:API、GraphQL、OpenAPI和CouchDB等， 在drupal中，构建解耦Drupal变得非常简单。您的技术需求将决定是否将解耦的Drupal作为您的下一个体系结构。

除了技术要求之外，组织因素也经常发挥作用。例如，如果事实证明很难找到具有Twig知识的、优秀的前端Drupal开发人员，那么雇佣更便宜的JavaScript开发人员并实现完全解耦可能更有意义。

什么东西是不能没有的?

正如我去年所写的，在对Drupal进行解耦时，任何决策中重要的方面都是项目所需的特性列表;编辑人员和开发人员的需求必须仔细考虑。在你的评估过程中，权衡不同的优点和缺点是关键的一步。每个项目都应该对其组织范围内的需求进行清晰的评估。

许多编辑和营销团队选择特定的CMS是因为它的布局功能和丰富的编辑功能。例如，Drupal允许编辑人员在浏览器中构建布局，并将组件拖放到浏览器中，而不需要开发人员来完成这些工作。尽管可以在客户端上重新构建CMS中可用的许多特性，但这可能是一个耗时且昂贵的过程。

近年来，开发人员的经验也成为一个重要的考虑因素，但不是以一竞技可能期望的方式。尽管JavaScript环境中的许多变化是开发人员更喜欢非耦合Drupal的动机之一，但现在有多种方法为Drupal编写前端，这使得人们更容易找到从事非耦合Drupal项目的人。例如，许多组织发现很难找到有Twig经验的、优秀的前端Drupal开发人员。转向javascript的前端可以解决其中一些资源挑战。

开发人员优先处理的需求，和编辑优先处理的需求，之间的平衡将指导您找到满足您需求的正确方法。如果您所在的组织主要是编辑组织，那么解耦Drupal可能会有问题，因为它减少了编辑可视化的控制。同样，如果您是拥有更多开发人员的组织机构，那么完全解耦的Drupal会加速开发的进度，同时关键的编辑功能消失了。

要考虑当前和未来的趋势

在过去的一年中，JavaScript框架变得越来越复杂，而静态站点生成器变得不那么复杂。

我听到的关于JavaScript的一个常见抱怨是，由于复杂性的增加，导致了碎片化的显示以及缺乏凝聚力。而这也是静态站点的动力。两年前，大多数JavaScript开发人员会选择Angular或Ember这样的全功能框架来创建简单的网站，而现在他们可能会选择静态的网站生成器。静态站点生成器仍然允许他们使用JavaScript，但它更简单，因为性能考虑和构建过程被转移到托管服务，而不是开发人员的责任。

我预计静态站点生成器将在未来一年获得发展势头，因为它们提供了积极的开发经验。静态站点生成器也吸引了经验丰富和经验不足的开发人员。

结论

Drupal仍然是解耦CMS体系结构的理想选择，而且它只会越来越好。API优先项目在准备JSON:API模块以便将其包含到Drupal核心方面取得了良好的进展，管理UI和JavaScript现代化项目正在使用一个重新设计的管理界面来改进Drupal的web服务。Drupal对GraphQL的支持不断改进，现在甚至有一本关于Drupal解耦主题的书。很明显，今天的开发人员有很多方法可以使用Drupal为解耦架构提供丰富的特性。

随着将完全解耦的静态站点作为开发人员可以选择的另一种体系结构范例的引入，体系结构的可能性比以前更加广泛。这意味着我去年定义的解耦Drupal方法的范围变得更加广泛。这种灵活性继续将Drupal定义为一种优秀的CMS，适用于传统方法和解耦方法，其特性远远超出Drupal的竞争对手，包括WordPress、Sitecore和Adobe。无论您的团队组成如何，也不管您的组织需要什么，Drupal都为您提供了解决方案。

特别感谢Preston So和Angie Byron、Chris、Gabe sullivan、Lauri Eskola、Ted Bowman和Wim Leers在撰写过程中提供的反馈。

可访问的流程图

这是本文前面的流程图图像的可访问和描述版本。首先，让一竞技列出可用的架构选择:

1. 耦合的。在不使用JavaScript的情况下使用Drupal(并将其作为其他使用者的内容存储库)。

2. 逐步分离。使用Drupal进行初始呈现，顶部是JavaScript(并作为其他使用者的内容存储库)。

3. 完全解耦的静态站点。使用Drupal作为静态站点生成器的数据源，如果需要，还可以部署到JAMstack托管平台。

4. 完全解耦的应用程序。将Drupal用作其他用户访问的内容存储库(如果是JavaScript，则使用Node)。用于服务器端呈现的js)。

其次，问一个问题“你打算建立什么?”并在“一次经历”或“多次经历”中选择答案。

如果您正在构建一种体验，可以问“它是网站还是web应用程序?”，并在“是，单个网站还是web应用程序”或“不是，Drupal仅作为非web应用程序的存储库”中进行选择。

如果您正在构建多种体验，可以问“它是网站还是web应用程序?”，回答“是，Drupal作为网站和存储库”或“不是，Drupal仅作为非web应用程序的存储库”。

如果您对上一个问题的回答是“否”，那么您应该构建一个完全解耦的应用程序，您的决策就完成了。如果您对上一个问题的回答是“是”，那么可以思考“项目中是否存在一些不可或缺的东西?”

编辑和开发人员的需求都是项目不可或缺的，下面是关于您的项目的一些问题:

编辑需求

1. 编辑是否需要在没有开发人员的情况下操纵页面内容和布局?

2. 编辑需要内置工具，比如就地编辑，背景链接工具栏吗?

3. 编辑需要在没有自定义开发的情况下预览未发布的内容吗?

4. 编辑器需要像Drupal的HTML那样默认访问内容吗?

开发者需求

1. 开发人员需要控制可视化而不是编辑?

2. 开发人员是否需要服务器端呈现Node.js构建功能?

3. 开发人员需要来自api的JSON并为前端编写JavaScript吗?

4. 开发人员需要的是公开且无法访问的CMS数据安全性吗?

如果，在问了所有这些关于您的项目不能没有的东西的问题之后，您的回答表明您的需求反映了编辑和开发人员的混合需求，那么您应该考虑一个逐渐解耦的实现，您的决策就完成了。

如果您对项目中不能缺少的内容的回答表明您的需求完全反映了开发人员的需求，那么您可以询问“它是静态的网站还是动态的web应用程序?”并在“静态”或“动态”的答案中进行选择。如果您对上一个问题的回答是“静态的”，那么您应该构建一个完全解耦的静态站点，您的决策就完成了。如果您对上一个问题的回答是“动态的”，那么您应该构建一个完全解耦的应用程序，您的决策就完成了。

如果你对项目中不能缺少的东西的回答表明你的需求反映了纯粹的编辑需求，那么问两个问题。问第一个问题，“页面的某些部分需要javascript驱动的交互吗?”如果您对第一个问题的回答是“是”，那么您应该考虑一个逐步解耦的实现，您的决策就完成了。如果您对第一个问题的回答是“不”，那么您应该构建一个耦合Drupal站点，您的决策也完成了。

然后，问第二个问题，“您是否需要通过API访问多个数据源?” 并选择“是”或“否”的答案 如果您对第二个问题的答案是“是”，那么您应该考虑逐步解耦的实施，并且您的决策已经完成。如果你对第二个问题的答案是“否”，那么你应该建立一个耦合的 Drupal站点，你的决策也完成了。