STAR Apps：用于开发工作流程的新一代前端工具-CSDN博客

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

其中一些包括：

视觉一致性：表示为设计系统（请勿与模式库或样式指南相混淆），通常使用诸如样式组件之类的库和诸如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％的Internet提供支持。

在随后的20年中， Web平台（尤其是JavaScript ）的发展导致“前端”学科的发展，作为对“后端”服务器端问题的补充。通过组合阿特伍德的法律和梅特卡夫的预测在网络上通过本地平台的胜利，这些努力最终导致重新想象单片架构的跨越前端和后端。最显着的封装形式是由Val Karpov在2013年创造的MEAN堆栈，提供“全堆栈” JavaScript替代方案，包括MongoDB（用于NoSQL数据存储），Express和Node（用于编写Web服务器）和Angular（用于编写反应式用户界面）。

发生了什么变化

但是，在过去五年中，MEAN堆栈和全堆栈JavaScript整体模型的理想化趋势不断消退：

相反，每一个开发人员编写定制的端点，API已经成为一个经济自身有相似的公司条纹， Twilio和Zapier通过其API的强度纯粹增长。
2014年对Firebase的收购和AWS Lambda的发布以及随后的无服务器革命，使得进行自己的无差异服务器管理和可靠性工程的概念吸引力降低了。
至于专有的后端，很明显，并不是所有的后端环境都将用JavaScript编写，尤其是随着其他语言框架（包括Rails ， Laravel和.NET ）以及新兴语言（如Go）的持续强大，尤其如此。甚至Express.js和Node.js的创建者也完全放弃了 JavaScript开发。

这意味着产品工程师的堆栈和主要工作已经比MEAN堆栈所设想的更加向 前端转移。克里斯将这种现象描述为一种现象，它赋予前端开发人员非凡的力量，这是因为在传统上被视为后端领域的前端工具的趋势。前端工程也得到了发展，主要是通过在我们已经使用的基础上逐步添加约束层-在我们的应用程序制作方法中添加设计理念，类型，架构和组件结构。

为什么所有这些改变？别改变了！

事实是，我们现在生活在一个产品和业务需求现在都要求将Web应用程序（包括移动Web）工程与Android，iOS和桌面本机应用程序开发相提并论的世界中，而我们不同的Web开发工具仍然令人担忧与那些范围狭窄的生态系统相比还不够。这并不是说旧的工具集有天生的错误，也不是说新的工具集是完美的。相反，这些更改可以视为对产品团队基本需求的回应：

更强大的 类型：类型检查不是万能的，也不替代测试的需要，但它确实可以提供更好的工具并提高代码的置信度。正如Thoughtbot的Chris Toomey所展示的，TypeScript和GraphQL为客户端和API做到了这一点。 Netflix的Lauren Tan将这一想法进一步提出了完整的端到端“ 强类型图” 。
集成的设计师/开发人员工作流程：对手动代码测试和设计审查的依赖无法扩展。设计系统现在是有关组织中可重复使用组件的方式和原因的全面文档。 Brad Frost展示了如何使用Gatsby为样式指南和设计系统工作流设置“车间”和“店面”环境。诸如Sketch和Framer之类的设计工具甚至已经开始将React和设计紧密集成到简化的工作流程中。 TypeScript和GraphQL都还提供了与TSDoc ， GraphiQL和相关的IDE集成紧密耦合的自文档功能。
针对变更进行了优化：随着产品团队采用迭代式敏捷冲刺和拆分测试，使用包含增量调整的灵活范式变得越来越重要。 React团队的Dan Abramov称之为“第二阶” API设计-对不断变化的需求具有鲁棒性。通过使用TypeScript，TypeScript大大缩短了反馈循环，可以轻松地以惊人的速度组成可重复使用的组件。 Airbnb的Adam Neary展示了一个在生产中使用React和Apollo GraphQL进行重构和迭代的绝佳示例。

请注意，本文中的“产品团队”主要是指产品工程团队，尽管通常情况下，产品设计和产品管理位于同一地点或投入大量频繁的信息。因此，工程工作流程必须明确考虑它们。

其余边疆

信不信由你，我是描述性的，而不是描述性的；我不建议大家扔出他们的代码并开始编写STAR应用程序。相反，我正在观察并指出我所看到的趋势，即优秀的产品团队都聚集在这种新模式上。他们可能只是在做某事。

但是，我不相信进化已经得出结论。还有需要更广泛的共识，这导致了现代Web应用程序开发过许多重要方面大杂烩定制的或一次性的解决方案和检查清单。 一个重要的是性能。 在过去五年中，台式机和移动设备上发布JavaScript的平均数量翻了一番。如果用户在加载之前导航离开，那么世界上所有出色的Web应用程序工程都将一事无成。传统的解决方案是（通常是手动滚动）服务器端渲染，后来由Next.js和After.js之类的框架进行管理。但是，这仍然需要运行和管理服务器，因此静态渲染解决方案（如Gatsby和React-Static）已经流行起来，可以直接将应用渲染为静态标记，以便在以后懒惰地补水（ JAMstack的最后一部分）。渐进式Web App技术和模式可帮助加快后续加载速度，并可以替代本地体验。