这个想法来自于过去：CGI。在Internet刚开始的时候，人们一直在编写一个简单的脚本，它通过STDIN(标准输入)接收传入的字节，并写入STDOUT(标准输出)。应用服务器(也称为CGI服务器)接受客户端，调用脚本，并将套接字输入/输出重定向到脚本。这里有很多细节，但这只是一个简短的解释。
20多年后，世界开始旋转，来到了最初的阶段：无服务器函数/lambda等等，几乎是CGI，除了脚本变成了码头容器，我们需要更多的服务器来做以前一样的事情。
所以让我们走捷径：我们有一个值得信任的开发人员(我们自己，公司员工-意味着它不是武断的客户端)，所以我们不需要对应用程序进行严格的限制，所以让我们丢弃docker和另一个笨重的员工。
因为我想写一些小的处理程序，99%的时间里什么都不做。我已经在为最便宜的数字海洋付费了(感谢你们的存在)，我不想额外付钱给像谷歌/亚马逊/Azure这样的Lambda提供商。
我也尝试过基于k3s的自托管解决方案，但它对于1 GB服务器来说太重了(是的，我不相信市场营销)。
所以，因为我是开发商，所以我决定自己做轮子；-)。
如果函数包含Makefile和已安装的make，则可以通过UI/API调用目标(称为操作)。用于安装依赖项或生成。
每个函数至少包含一个URL：<；基本URL>；/a/<；UID>；和任意数量的唯一别名/链接<；基本URL>；/l/<；链接名称>；。
链接对于创建公共链接和在实际实现(函数)之间动态迁移非常有用。例如：您用Python语言制作了一个GitHub钩子处理器，然后改变主意，改用PHP函数。您可以只更改一个链接，而不是更新GitHub repo中的链接(如果您将其散布到任何地方，这可能会很麻烦)。