一个 库足以取代一整个工程团队我猜你现在的电脑里一定塞满了各种各样的技术栈。你或许才刚刚为了呈现几个数据图表, 娴熟地构建起Flask后端, 又在另一处摆弄React框架, 顺带为了前后端通信编写了一堆连自己都觉着繁复啰嗦的API胶水代码, 又或许, 为了运行一个每日凌晨两点方才执行一回的简易脚本, 你不得不维护一套庞大且沉重得很的工作流引擎。我们好像深陷于这般一种奇特圆圈当中, 每隔一年, 我方所运用的技术架构便持续朝着更过于庞大、繁杂、笨重的方向发展, 新增了数量更为可观的服务、增添了更多的监控仪表盘设置展示, 还涌现出来规模更为庞大、超出一般认知理解能力、更有甚者即便业内专家也可能难以通晓的那些 YAML 配置文件。身为一名于代码堆中摸爬滚打, 在凌晨三点时分仍面对报错信息的开发者, 你必定曾问过自己这般一个问题: 为何自己需要运行五个复杂工具, 然而明明一个库便能够搞定这所有一切呢?这篇文章并非意在去营销那些仅仅能够用于编写简单示例功能的入门级工具, 我们要说的是那些拥有“技术栈影响力”的库, 这般强大的它们, 鉴于它们自身的特点在各自所属的领域范围之内, 正以一种悄然无息的态势替换整整一类别的工程工具, 我曾经在实际生产运行的环境当中亲自使用过其中的大部分, 其有些事例为我节约了数周工期的工程时间, 有些事例则促使我进行深切细致的反思, 自己之所以当初会选择过度设计究竟是出于何种缘由。要是你已然告别了仅会依据教程敲代码的新手阶段, 转而变为对代码的简洁程度以及效率秉持近乎偏执般追求的实干人员, 那么这九个库会对您的开发边界予以重新定义。告别前后端撕裂的旧时代让咱们先来谈谈那最令人头疼不已的“全栈工程”。在传统的认知范畴当中, 要是你打算去做一个内部销售的仪表盘, 那你就得历经一整套标准流程, 用 Flask 来做数据接口, 用 React 或者 Vue 去做前端展示, 中间还要套上一层极为繁杂的认证逻辑, 最终还得去折腾部署配置。的出现彻底终结了这种疯狂。它后头暗藏着的想法特别质朴: 既然你已然借助 完成了逻辑编写, 为何不能够直接靠着 将界面也给制作出来呢? 在 的范畴内, 不存在 HTML, 不存在 , 甚而不存在明晰的 API 调用。你仅需如同撰写脚本那般导入 将数据加以处理, 进而调用一个简易的 函数, 一个具备交互性的 Web 应用就出世了。这算不上是那种放置在实验室里供人赏玩之物, 网飞的团队在其内部将其加以运用, 优步的团队同样于内部使用它。当你觉察时方知, 原本需要一整个前端团队协力配合方能达成的工作量, 借助几十行代码便可如愿以偿, 此刻你就会领悟到, 那些为了内部工具而构建起来的繁杂 React 架构体系, 于某种程度而言真是对资源的极大挥霍浪费。接口开发的暴力美学要是讲, 把界面的繁杂给处理好了那么呢, 这就是在对 API 开发的极限发起挑战了。许多人错误觉得, 仅是一个“速度更快的Flask”。实则不然, 其乃是把Flask的灵活性、功能性以及规范性融合起来而形成的结果。在传统开发方式下, 为使API具备可靠性, 你需要手动处理请求校验、响应序列化, 并且还得额外耗费精力去维护那份始终赶不上代码进展的文档。的设计者极为巧妙地运用了 的类型提示Type Hints, 你所写下的每一个函数参数类型, 会自动转变为数据校验规则、自动化的文档说明以及成效显著的异步支持, 不存在插件, 不存在多余的样板代码, 仅仅拥有纯粹的类型安全, 在性能测试里, 它甚至能够和 Node.js 或者 Go 语言相抗衡。它所正在取代的, 不光是传统的框架, 更是诸多开发场景, 就是那一些为了追求性能, 而不得不转向复杂语言的开发场景。自动化流转的极简哲学当说起任务调度时, 大家头一个想到的常常是 Cron 或者是重量级的那个, Cron 是挺简单的, 可一旦它于凌晨两点毫无征兆地失败了, 那对开发者而言简直无疑是场噩梦, 那另一个呢, 它明显过于沉重了, 夸张到甚至于你只是要运行几个简单的相关任务, 却必须得先去维护一整套颇具规模的调度架构。给出了一种具备更强烈当代感觉的挑选, 它能够被观测, 能够被重试, 能够被调试, 然而其又轻盈得好似寻常的一个装饰器。你仅需于你的函数之上添加一个 flow 或者 task, 立马就具备了任务重试机制、日志记录、状态跟踪以及失败告警。它无需你去变更编写代码的方式, 仅仅是给你的代码加持了一层坚实的防护。对于百分之九十的团队而言, 那种过度工程化的配置实际上是没必要的, 能够凭借百分之十的上手难度处理掉绝大多数现实世界中的工作流问题。数据处理的降维打击于的数据科学版图里, 几乎仿若神明般的存在。然而当数据量越过某一临界点后, 其内存占用状况以及单线程时出现的瓶颈会致使你有种力不从心的感觉。以前的解决办法是搬来 Spark 这种堪称分布式计算的厉害工具, 可这同时也就意味着你引入了极为繁杂的集群管理方面的成本。的出现让这种尴尬的局面发生了逆转。将其作为以 Rust 开发而成的库, 它于本地机器上展现出令人惊叹的战斗力。它对惰性执行予以支持, 也就是 Lazy 模式, 默认状况下呈现多线程并发, 并且内存占用远远低于其他。于实际测试期间, 它处理相同任务时的速度常常是其他的 5 至 10 倍。它证实了一件事情: 在多数分析场景当中, 你并非需要一个价格高昂的计算集群, 你仅仅需要一个更为高效的本地库。数据验证与模型的“统一场”要是你的代码库之中, 依旧有大量依靠手写的if判断, 用来查验JSON数据格式, 亦或是使用差异化的库, 分别去处理数据库模型以及数据验证, 那么你务必得瞧瞧 和。把 的类型系统转变成了运行时的安全保障, 它并非仅仅在校验数据, 而是在解析数据, 这种设计理念得以如此成功, 致使 全部的底层逻辑都构建于其之上。而那体现为在数据库范畴内该理念的延展。它是由那位作者亲自构建造就, 尝试去化解一个由来已久的棘手问题: 为何我得耗费精力去撰写一套用于数据库的模型, 接着又另行编写一套用于验证的模型呢? 要将两者一体化融合。即一个单一的模型, 既充当作数据库的特定角色, 同时又是 API 的验证工具。这样的设计举措消弭了不同层面之间那种不协调的感觉, 并且还消除了那些为了实现数据转换而存在的重复性代码。浏览器自动化的新秩序你要是仍在承受, 充斥着慢得跟蜗牛似的且动不动就崩溃的测试套件, 那仿佛是从未来穿越归来的工具。