Fóir 为什么存在

八年来为别人构建软件，几乎每个项目都有同样的缺口。内容管理系统能帮你走完大部分路程，它没有覆盖的那一部分，才是预算花掉的地方。

Fóir 出自一家为客户交付软件的工作室。各个项目的产品各不相同，但底层每一个都需要同样的部分：编辑无需开发人员就能修改的内容、归属特定用户的数据、登录、文件存储、定时任务，以及关于谁可以看到什么的规则。

我们在一个又一个项目上构建这些部分，每一次都让我们更了解它们应如何组合在一起。项目做得足够多之后，这些模式不再变化，为每个客户重新构建一遍也就越来越没有意义。

现成的 CMS 几乎能满足需求。接着是它原本就不会做的那部分：登录后的区域、因客户而异的内容、需要接入另一个系统的工作流。

到这一步有三条路，每一条都有代价。运行两套系统，并在它们之间编写集成。自己构建后端，再把第三方 CMS 挂在旁边。或者自己构建后端，并重新构建你的团队本来就会用的编辑工具。这三种方案我们都报过不止一次价，而它们没有一个是别人真正想买的东西。

更便宜的开发本应让最后这一部分变得负担得起。结果它变得频繁了。受托构建应用的智能体，会在每个项目里拼装同样缺失的部件：登录、数据库、文件存储、权限、作业队列。其中大多数对安全至关重要，而你只能相信它每一次都把它们正确地接在了一起，而且是在一个没有人从头到尾读过的代码库里。

有了 Fóir，这些部件到手时就已经接好，并由我们运行。智能体编写你的产品特有的部分，所在的后端有一套它无法省略的访问规则。

拼装出来的后端，其失败是悄无声息的：某条没人走过的路径上的检查、缺了一个子句的查询、触及范围超出持有者本人的密钥。

对于不存在的东西，你无法通过审查获得信心。有效的办法是一个检查不可能被遗漏的系统。在 Fóir 中，访问规则编译成数据库自身的行级安全，所以忘了做检查的查询只会返回其调用方有权看到的内容，而新表在有人决定它如何受保护之前，会让我们的测试失败。负责编译的引擎是 Demesne，它是开源的。

Fóir 是我们自己工作的起点。本站就运行在它上面，我们新的客户项目也在这里交付。我们过去在每次构建时都要重新做的决定，例如内容如何建模、如何让用户的数据归其所有，现在只做一次并保留下来。

后端既要编写也要运营，所以 Fóir 是一项托管服务。其中决定谁能看到你的数据的部分，对任何人公开可读。

每个项目都要付费，把同一个基础重新建一遍。

Fóir 就是这个基础，由我们替你运行：结构化内容和应用数据在同一个运行时中，托管登录、媒体、个性化、自动化和生成的 API 已经接在一起。你从自己的业务逻辑开始。

它取代了什么

它所替代的订阅和构建项目，集中在一处，一张账单。

编辑界面、schema、草稿和版本历史。

为你自己的用户提供登录，使用你自己的域名，并配有相应的角色。

上传、图像转换、视频流，以及它们前面的分发。

跨记录的全文搜索，以及用于按含义检索的向量。

定时计划、后台操作、重试，以及失败记录的去处。

事务性邮件、应用内消息和推送，偏好按客户保存。

否则要把上述六项连在一起的代码，以及它们之间的偏差。

没有需要你保持更新的服务器，也没有升级周末。

每一项能力，以及那些我们直接说明改用哪个工具的对比。