与 WordPress 和 Drupal 的解耦架构

一则或许对你有用的小广告

欢迎加入小哈的星球 ,你将获得:专属的项目实战 / 1v1 提问 / Java 学习路线 / 学习打卡 / 每月赠书 / 社群讨论

  • 新项目:《从零手撸:仿小红书(微服务架构)》 正在持续爆肝中,基于 Spring Cloud Alibaba + Spring Boot 3.x + JDK 17...点击查看项目介绍 ;
  • 《从零手撸:前后端分离博客项目(全栈开发)》 2 期已完结,演示链接: http://116.62.199.48/ ;

截止目前, 星球 内专栏累计输出 63w+ 字,讲解图 2808+ 张,还在持续爆肝中.. 后续还会上新更多项目,目标是将 Java 领域典型的项目都整一波,如秒杀系统, 在线商城, IM 即时通讯,权限管理,Spring Cloud Alibaba 微服务等等,已有 2200+ 小伙伴加入学习 ,欢迎点击围观

6 月,我有幸与 Pixo 的 Brandon Bowersox-Johnson 和来自 Four Kitchens 的 Mike Minecki 主持了一场网络研讨会,讨论他们在客户项目中使用解耦 CMS 架构。太棒了—— 录音现在可以用了 ——而且显然目前对这个话题很感兴趣。 查看我们的 Decoupled CMS 资源页面。

这种兴趣包括我自己的。网络研讨会是在我上个月 在洛杉矶 DrupalCon 上与来自 Gizra 的 Amitai Burstein 就 Decoupled Drupal 进行的 演讲之后举行的,在那里我无法抑制对这个话题的热情。

除了聪明的模因和时髦的 gif,兴奋是真实的,而且有充分的理由。以下是我们网络研讨会的要点。

整体和微服务(一切旧的都是新的)

对解耦(或“无头”)CMS 实施的整个讨论实际上是软件和互联网服务中更大时代精神的一部分:通过网络集成更多专业组件的世界的普遍趋势,而不是整体软件部署。这通常被称为单体与微服务。

重要的是要认识到这场辩论不是对与错的问题,甚至不是新与旧的问题。这两种架构都存在了很长时间,并且各有利弊。这场辩论本身并不新鲜。 Linux 爱好者可能认为它是 大教堂和集市 的历史回声。

人们考虑解耦的方式有很多种,从使用原生移动应用程序在 CMS 前端到利用最新 JavaScript 框架的浏览器内交互体验,再到使用静态站点生成器而不是集成的“主题”。

后一种方法是我们在 Mike 和 Brandon 的案例研究中讨论的。

使用最好的工具提供最好的体验

这两个项目的主要动机是在网络、平板电脑和移动设备上提供一流的用户体验。在过去的几年中,我们在现代设计的工具和技术方面进行了巨大的创新,但是以紧密耦合或“单体”方式将这些快速发展的显示与 CMS 集成起来可能既复杂又笨拙。

通过分离站点的 UX 层,Pixo 和 Four Kitchens 不仅能够利用他们选择的工具,而且还能够独立于后端 CMS 对其进行迭代。通过这种方式,前端可以真正敏捷,适应客户请求和技术创新。

面向未来和可扩展性

同样,对于 Pixo 和 Four Kitchen 的客户来说,投资分离基础设施的部分吸引力在于降低未来重新设计的复杂性(和成本)。架构解耦,不仅是前后台开发工作的解耦,还有升级更新的时间表和工作量的解耦。

此外,通过将 CMS 实施为与客户端无关的 JSON REST API,打开了其他创新渠道的大门。多个前端可以独立运行。就四厨房在 twit.com 上的工作而言,这甚至包括一个渴望开发自己的利用网站内容的“应用程序”的客户社区。

“再次爱上 CMS”

两个案例研究中最令人难忘的事情之一是 Mike 和 Brandon 如何谈论追求解耦架构如何重新获得他们对使用所选 CMS 的欣赏和享受。通过让 Drupal 和 WordPress 发挥它们的优势——内容组织和编辑——并避免大量复杂的自定义代码,Pixo 和 Four Kitchens 重新发现了他们对这些核心 CMS 产品的热爱。

此外,在别处处理演示意味着将 CMS 重新聚焦于内容,将编辑用户置于聚光灯下。这意味着这些角色的用户体验会更好,这使得最活跃的用户更有可能再次爱上这些网站。

释放生产力——API 规范是关键

除了取悦客户之外,迈克和布兰登还谈到了这些项目如何在内部取得成功。开发人员更快乐,项目享有良好的速度、敏捷性和效率。

在流程方面,同意 API 规范是在两个项目上解放这种生产力的关键。在前端和后端之间拥有 API“合同”意味着两者都可以以自己的速度独立运行。

这允许像浏览器中设计这样的技术,四个厨房有效地利用了这些技术。 Pixo 使用 在线 API 文档和测试服务 Apiary 报告了良好的结果,以最大限度地减少团队之间的“偏差”。

最佳实践仍在涌现

解耦架构仍然是相当新的。虽然技术越来越好,但这条路仍然不是任何人所说的老路,而且肯定有潜在的陷阱。

特别是,使用独立的前端意味着放弃一些来自单体 CMS 的“免费赠品”。诸如内容预览和简单的字符串翻译之类的东西。但是,只要意识到权衡取舍,就可以轻松解决这些问题。

也没有组合无头实现的“灵丹妙药”——事实上,由于所有不同的用例,可能永远不会有——但在这方面有好消息。随着越来越多的开发人员和机构分享他们的方法和堆栈,甚至开源他们的内部工具,我们正在取得进展。

在 Four Kitchen 的案例中,他们使用了他们贡献的 RESTful 模块 ,以及他们开发和发布的名为 Saucier 的 NodeJS 框架。

Pixio 使用了 JSON-REST-API 插件 ,该插件计划在其 下一次迭代 中移入核心,以及一个名为 Patternlab 的开源“原子设计”工具,以及一个名为 Outpost 的基于 Symfony 的 PHP 前端工具,它们是开源的在 getoutpost.org

虽然这些工具链尚不代表完整的解决方案,但随着越来越多的专家和实施者做出贡献,开发的步伐将继续加快。根据我在这些案例研究和其他地方所看到的情况,解耦架构已经存在了令人兴奋的几年,并且越来越多的机构和客户利用了它的优势。



相关文章