我们正在构建没有Web前端的CLI First PaaS

在这忙碌的一年开始，我加入了Micro，一个开源的微服务平台。这家公司诞生于围棋框架。我们采用了框架的概念-服务发现、配置和其他组件的接口，这些组件可以在任何实现(从本地MDN到Kubernetes)上运行，并提供它的实时平台版本。它有点像Netlify，但在后台。

一旦我们对微服务器和CLI的本地开发流程感到满意，我们就决定开始将该产品作为一个平台进行销售。建立一个网站似乎是显而易见的一步。现在是2020年，对吗？

所以我们得工作了。带有漂亮图表的指标。追踪。呼叫服务。列出终结点。一切都进展得很顺利。但慢慢地，我们肯定开始遗漏了我们在CLI前端习惯的功能。作为非常频繁的命令行用户，每当我们在CLI中获得可用的内容时，我们都会首先到达那里。

然后我们意识到。我们到底是谁在建设这个前台？为什么？我们更喜欢命令行。我们数以千计的用户中没有一个人要求使用Web用户界面。至多，它被认为是一件“酷”的事情。

过去的三十年都是关于万维网(WWW)的，在这一过程中，我们已经经历了多次重复，以建立“网络优先”的体验，我认为这真的在00年代中期的Web2.0时代达到了顶峰，Facebook和其他公司也是如此。在某种程度上，我们进入了“移动优先”的时代，但对于开发者来说，Web仍然是一个可怕的平台，我们在任何平台或工具上都是如此。AWS是一个很好的例子，说明了如何真正犯错。如果新的产品和平台要先移动，也许我们作为开发者需要首先使用CLI。所以就是这样了。M30是CLI的首次体验。没有上下文切换，没有难看的仪表板，只有一个简单直接的命令行实用程序，当你需要它的时候，它就会离开你的道路。我们希望Micro能从这次经历中学到更多东西，完全摆脱Web UI。挑战你所知道的关于Web用于后端开发的所有假设，并思考，我是否真的需要它，或者它更适合作为一种单一的CLI体验。

所以我们加倍下注。我们完全搁置了网页界面，决定支付将是网站上唯一的事情，应该在终端提供卡的细节感觉粗略。

我们在这之后的发现让我们很惊讶。通过限制我们的选择，我们释放了一场关于如何改善我们表达思想的单一媒介的想法风暴。

从表面上看，这似乎并不多，但当你生活在并呼吸着这些命令时，它会提供一种巨大的满足感，哪怕是很小的摩擦也能消除。

新服务及其端点感觉就像内置微命令，这就是为什么我们的邀请函简单地变成了。

向最终用户交付功能变成了部署一项新服务，用户可以轻松地通过编程从终端调用他们的终端。

Bash在快速和信息密集的一次性脚本上大放异彩，因此我们的端到端测试框架是为使用Micro CLI命令编写测试而构建的。

我们梦想着一个编程尽可能接近自然语言的未来。目前，bash的无处不在为我们快速与微服务交互提供了一个很好的层面。这真的让人感觉这个平台是活的，因为服务作者正在创造名词和动词，并将它们组合成句子。

你为什么不试一试呢？我们有免费的一层；)。