Wrangler的最新更新版本1.3.1为构建Cloudflare worker的开发人员引入了重要的新功能，从内置部署环境到对Workers KV的一流支持。Wrangler是Cloudflare首个官方支持的CLI。对于我们的工程师和Cloudflare工人的产品人员来说，进入软件领域是一种全新的体验团队。作为作为1.3.1发行版的一部分，Workers开发人员体验团队的成员们投入到为CLI构建特性和像用户一样思考的过程中。因为虽然我们希望构建一个CLI就像我们的队友Avery tweet所说的那样简单……如果我在编程一个CLI，我会简单地以一种没有争议的方式来设计它，并且适合每种类型的用户。—Avery harnish（@SmoothAsSkippy）2019年8月28日…它带来了我们许多人从未遇到过的设计挑战。要成功地克服这些挑战，需要对整个团队的用户产生深刻的共鸣，以及解决与开发人员编写方式相关的模糊问题的能力工人。牧马人，meet Workers KVOur的新KV功能引入了一系列新功能，从创建KV名称空间到批量上载密钥-值对以供工人内部使用。这个新功能主要由与Workers KV API交互的逻辑组成，这意味着"引擎盖"下的技术工作相对简单。然而，弄清楚如何向Wrangler用户清晰地表示这些新特性成为了这方面的基本问题发布。设计对新的KV功能的调用需要多次迭代，这一过程教会了我们很多关于可用性的知识！尝试1我们的第一次传球，这条路原来看起来很明显。（旁白：真的，真的不是）。我们假设让Wrangler支持熟悉的命令（如ls和rm）是将熟悉的命令行工具映射到Workers KV的一种合理的映射，最后得到以下一组调用：#创建一个新的KV名称空间$wrangler kv添加myNamespace#设置不过期的字符串键$wrangler kv set myKey="someStringValue"#设置多个关键点$wrangler kv set myKey="someStringValue"myKey2="someStringValue2"。。。#设置60秒后过期的易失性（过期）密钥$wrangler kv set myVolatileKey=path/to/value--ttl60s#删除三个键$wrangler kv rm myNamespace myKey1 myKey2 myKey3#列出所有命名空间$wrangler kv ls公司#列出命名空间的所有键$wrangler kv ls myNamespace#从命名空间移除所有键，然后移除命名空间$wrangler kv rm-r mynamespace虽然这些命令调用了熟悉的shell实用程序，但它们使与kv名称空间的交互更像是与文件系统的交互，而不是与键值存储库的交互。将一个像ls这样的著名命令与一个非命令set并置是令人困惑的。此外，将预先存在的命令行工具映射到KV操作并不是一个好的1-1映射（尤其是对于rm-r；如果您只需要删除名称空间，就不需要像目录一样递归地删除KV名称空间！）这个草案还提出了我们需要支持的用例：也就是说，我们需要支持像从文件中轻松批量上传这样的操作。该草案要求用户在命令行中输入每个KV对，而不是从键值对的文件中读取；这也是一个-开始。最后，这些KV子命令导致了对不同资源的操作的混乱。例如，列出Workers KV名称空间的命令看起来很像在名称空间中列出键的命令。今后，我们需要会见这些新确定的需要。尝试2我们的下一次尝试放弃了shell实用程序，转而使用诸如create、list和delete等简单的声明性子命令。它还允许用户向Wrangler传递一个包含键和值的JSON文件，从而满足了对易于使用的批量上载的需求$wrangler kv创建名称空间#删除命名空间$wrangler kv delete namespace#列出命名空间$wrangler kv list命名空间#使用可选的过期标志将键值对写入命名空间$wrangler kv write key--ttl 60s#从命名空间中删除键$wrangler kv delete key#列出命名空间中的所有键$wrangler kv list key#写大量kv对。可以是json文件或目录；如果dir键是根目录下的文件路径，则值将是文件的内容$wrangler kv批量写入./path/to/assets#删除批量对；与上面相同的输入功能$wrangler kv delete bulk./path/to/assets鉴于我们计划引入的新功能的广泛性，我们还构建了新子命令的分类法，以确保对不同资源的调用（名称空间、密钥、，和大量的键值对集-是c一致性：设计调用随着分类法成为我们未来开发过程中的一个关键部分，它让我们清楚地看到了我们新KV的"大局"特色。这个这个方法更接近我们想要的。它提供了大容量put和bulkdelete操作，可以从JSON文件中读取多个键值对。在指定了action子命令（例如delete）之后，用户现在显式地声明一个操作应用于哪个资源（名称空间、键、块），并减少了关于哪个操作应用于哪个KV的混淆组件。这个然而，草案仍然没有我们希望的那样明确。名称空间上的操作与键上的操作之间的区别并不像我们想要的那样明显，我们仍然担心不同的删除操作可能会意外地产生不需要的删除（可能是一个灾难性的结果！）尝试3我们真的想帮助区分用户在任何给定时间操作的结构层次结构的位置。在给定的操作中，它们是否在名称空间、密钥或大容量密钥集上进行操作，我们如何才能使其尽可能清楚？我们环顾四周，比较了从kubectl到Heroku处理影响不同对象的命令的方式。我们得到了一个受Heroku的CLI启发的令人愉快的模式：冒号分隔的命令namespacing:插件：install PLUGIN#将插件安装到CLI中插件：链接[PATH]#将本地插件链接到CLI进行开发插件：卸载插件#卸载或取消链接插件插件：更新更新已安装的插件，因此我们采用了kv:namespace、kv:key和kv:bulk来语义上分离我们的命令：#namespace命令在名称空间上运行$wrangler kv:名称空间创建[--env]$wrangler kv:命名空间删除[--env]$wrangler kv:命名空间重命名[--env]$wrangler kv:命名空间列表[--env]#按键命令操作单个按键$wrangler kv:key write=[--env |--ttl |--exp]$wrangler kv:键删除[--env]$wrangler kv:密钥列表[--env]#bulk命令将用户生成的JSON文件作为参数$wrangler kv:bulk write/path/to/数据.json[--环境]$wrangler kv:批量删除/path/to/数据.json[--env]最终以这个结束拓扑学：我们更接近于我们所期望的使用模式；对用户而言，所操作的对象是显式的，应用于对象的操作也很明确。只剩下一个使用问题。提供命名空间id（一个指定要对哪个Workers KV命名空间执行操作的字段）要求用户获取其笨重的KV命名空间id（一个类似于06779da6940b431db6e566b4846d64db的字符串）并在命令行中的namespace id选项下提供它。这个名称空间id值是我们的Workers KV API在请求中所期望的，但是对于用户来说，挖掘和提供这些值会很麻烦，更不用说频繁地使用了使用。这个我们的解决方案利用了牧马人.toml出现在每一个牧马人产生的工人。要发布使用Workers KV存储的Worker，需要在Worker的牧马人.toml：kv命名空间=[{binding="TEST_NAMESPACE"，id="06779da6940b431db6e566b4846d64db"}]此字段指定绑定到名称TEST\u名称空间的Workers KV名称空间，以便Worker脚本可以使用逻辑访问它例如：TEST\u NAMESPACE.get（"我的钥匙"）；我们还决定利用这一点牧马人.toml允许用户指定KV绑定名称而不是KV命名空间id的字段。提供KV绑定名称后，Wrangler可以在牧马人.toml并将其用于工人KV API打电话来。牧马人在KV名称空间上执行操作的用户只需为他们的KV调用提供--binding TEST_名称空间，让Wrangler从牧马人.toml. 如果用户的牧马人汤姆终于来了，我们达到了我们的快乐点：Wrangler的新KV子命令是明确的，为工人KV的个人和批量操作提供了功能，并觉得符合人体工程学的牧马人用户融入他们的日常生活行动。教训在整个设计过程中，我们确定了以下要点，以供将来的Wrangler使用工作：分类CLI的子命令和调用是确保一致性和清晰性的好方法。CLI用户倾向于在CLI中预期相似的语义和工作流，因此可视化地记录CLI的所有路径可以极大地帮助识别新工作与旧语义的一致性。绘制这些分类法还可以暴露缺失的功能，这些功能似乎是CLI"全局"的一个基本部分功能。使用其他CLI的灵感和验证。从流行的CLI中提取逻辑有助于我们确认关于用户喜欢什么的假设，并了解复杂CLI的既定模式调用。避免需要传入原始ID字符串的逻辑。大量测试cli意味着记住和重新粘贴ID值会很快变得非常乏味。强调一组纯人类可读的CLI命令和参数有助于获得更直观的体验。在可能的情况下，利用配置文件（就像我们所做的那样牧马人.toml)关