STAR 应用：面向开发工作流的下一代前端工具

从 AirBnb 和 纽约时报 到 Shopify 和 Artsy （以及许多其他公司）的产品团队正在融合一组新的最佳实践和技术，用于构建他们的业务赖以生存的 Web 应用程序。 这种趋势反映了我们可能共有的核心原则并解决了潜在的问题，因此值得深入研究。

其中一些包括

• 视觉一致性：呈现为 设计系统（不要与 模式库或样式指南 混淆），通常使用 styled-components 等库和 Storybook 等工具构建。
• 内部一致性：使用 TypeScript 等静态类型工具创建。
• 数据操作：这些与使用 GraphQL 的客户端（如 Apollo）协同工作。
• 数据表示：使用可重用组件和行为的库（如 React）显示。

给事物命名很难，我们的行业一直在努力为这一代用于 Web 应用程序的新工具命名。 令人难以置信的 Orta Theroux 将其称为 Omakase； 我简化了它，并选择了一个更简单的 首字母缩略词，从上面概述的工具中的字母中提取出来：STAR（设计系统、TypeScript、Apollo 和React）。

STAR 应用不是“又一个前端堆栈”。 它们涉及额外的意见和约束。 因此，STAR 应用也不一定容易。 它们有学习曲线。 单人开发者可能会发现 STAR 应用不必要地冗长，因为它们提前加载了沟通开销。 STAR 应用更多地与产品团队工作流有关，而不是与任何特定技术有关。

然而，我们发现越来越多的公司发现这个堆栈是一项值得的投资。 我们应该问为什么。

上下文：从 LAMP 到 MEAN

LAMP 堆栈 于 1998 年由 Michael Kunze 提出，用于描述 Linux、Apache、MySQL 和 PHP 的组合，这些组合是编写完整 Web 服务器的主要开源技术。 在这种模型中，所有渲染和逻辑都在服务器端完成，JavaScript 的作用非常有限。 时至今日，由于 WordPress 等长期建立的框架的流行，这种架构仍然是最常见的网站架构，它 为互联网的 30% 提供动力。

在随后的 20 年中，Web 平台的增长（特别是 JavaScript）导致“前端”学科的演变，作为对“后端”服务器端问题的补充。 通过结合 Atwood 定律 和 Metcalfe 对 Web 胜过原生平台的预测，这些努力最终重新构想了一个单片架构，以跨越前端和后端。 其中一个突出的封装是 MEAN 堆栈，由 Val Karpov 在 2013 年创造，以提供“全栈”JavaScript 替代方案，包括 MongoDB（用于 NoSQL 数据存储）、Express 和 Node（用于编写 Web 服务器）以及 Angular（用于编写响应式用户界面）。

发生了什么变化

然而，在过去的五年里，许多趋势已经削弱了 MEAN 堆栈和全栈 JavaScript 单片结构的理想。

• 与其让每个开发者都编写定制的端点，不如让 API 成为一个经济体，像 Stripe、Twilio 和 Zapier 这些公司仅仅依靠其 API 的力量而发展壮大。
• 收购 Firebase 和 推出 AWS Lambda（2014 年）——以及随后的 无服务器革命——使进行自己的非差异化服务器管理和可靠性工程的概念变得不再那么有吸引力。
• 至于专有后端，很明显，并非所有后端环境都将用 JavaScript 编写，特别是考虑到其他语言框架（包括 Rails、Laravel 和 .NET）的持续强大以及像 Go 这样的新兴语言。 即使是 Express.js 和 Node.js 的创建者也最终 放弃 了 JavaScript 开发。

这意味着产品工程师的堆栈和主要工作比 MEAN 堆栈设想的更转向前端。 Chris 将此描述为一种现象，它给前端开发者带来了非凡的 力量，因为前端工具的趋势正在扩展到传统上被认为是后端领域的东西。 前端工程也一直在发展，主要是在我们已经使用的东西之上逐渐添加一个约束层——为我们构建应用程序的方式添加设计理念、类型、模式和组件结构。

为什么会有所有这些变化？ 停止改变事物！

事实是，我们现在生活在一个产品和业务需求需要将 Web 应用程序（包括移动 Web）工程与 Android、iOS 和桌面原生应用程序开发相提并论的世界，而我们不同的 Web 开发工具与这些范围紧密的生态系统相比仍然很糟糕。 这并不是说旧的工具集有什么本质上的错误，或者新的工具集很完美。 相反，这些变化可以被视为对产品团队的潜在需求的回应。

• 更强的类型：类型检查不是万能药，也不 能取代对测试的需求，但它确实可以实现更好的工具并提高代码信心。 TypeScript 和 GraphQL 对客户端和 API 做到了这一点，正如 thoughtbot 的 Chris Toomey 所示。 Netflix 的 Lauren Tan 将这个想法更进一步，提出了一个完整的端到端 强类型图。
• 集成设计者/开发人员工作流：依赖于手动代码测试和设计审查无法扩展。 设计系统现在是关于如何在整个组织中重用组件的全面文档。 Brad Frost 展示了 如何使用 Gatsby 为样式指南和设计系统工作流设置“研讨会”和“店面”环境。 像 Sketch 和 Framer 这样的设计工具甚至开始将 React 和设计紧密集成到简化的工作流中。 TypeScript 和 GraphQL 还都提供了与 TSDoc、GraphiQL 和相关 IDE 集成紧密耦合的自文档功能。
• 针对变化进行了优化：随着产品团队拥抱迭代敏捷冲刺和拆分测试，使用灵活的范式来拥抱增量调整变得越来越重要。 React 团队的 Dan Abramov 将此称为“二阶”API 设计——对不断变化的要求的鲁棒性。 设计系统和 React 使得能够以惊人的速度组合可重用组件，而 TypeScript 则显着缩短了反馈循环。 Airbnb 的 Adam Neary 展示了一个使用 React 和 Apollo GraphQL 在生产环境中重构和迭代的精彩示例。

请注意，本文中的“产品团队”主要指产品工程团队，尽管产品设计和产品管理通常是共同工作的，或者有大量的频繁输入。 因此，工程工作流必须明确地将它们考虑在内。

剩余前沿

信不信由你，我是在描述，而不是规定； 我并不建议每个人都扔掉他们的代码并开始编写 STAR 应用。 相反，我观察并指出了我所看到的一种趋势，即优秀的产品团队都在融合这种新的模式。 而且他们可能真的发现了一些东西。

然而，我认为这种演变尚未走到尽头。现代 Web 应用程序开发中仍有许多重要的方面需要更广泛的共识，这导致了 杂乱无章 的自定义或一次性解决方案和清单。其中一个重要问题是性能。 在过去五年中，桌面和移动设备上交付的 JavaScript 平均数量 翻了一番。如果用户在加载完成之前就离开了页面，那么世界上所有的 Web 应用程序工程都是徒劳的。传统的解决方案是（通常是手工制作的）服务器端渲染，然后由像 Next.js 和 After.js 这样的框架进行管理。但是，这仍然需要运行和管理服务器，因此像 Gatsby 和 React-Static 这样的静态渲染解决方案变得流行起来，它们可以将应用程序直接渲染为静态标记，以便稍后延迟重新水合（JAMstack 的最后一块）。渐进式 Web 应用程序技术 和 模式 有助于使后续加载更快，并作为原生体验的可行替代方案。

待续…

随着这个故事的继续发展，我相信需要进行更多探索和实验，以简化学习曲线，让更多团队采用 STAR 应用程序工作流程。事实上，我在 STAR Labs 公开学习它，并邀请您一起参与。如果您有任何经验要分享或问题要问，请随时告诉我。