什么是飞布：
⻜布是可视化API公有云平台，面向开发者，以快速交付⽣产级 API 为⽬标。基于可视化开发+AI辅助，提升研发效率，解决前后端协作问题。
一、Hooks 无处不在
fireboom 中有大量模版方法的实践，包括认证前后，全局请求前后，当前请求前后的自定义逻辑。
在 java 中，会定义一个接口交由下层实现，上层通过接口类型在 spring 容器中找出所有 bean 实现并依次遍历调用。
而在飞布中，会将定义的 api 动态注册到路由中，同时定义的钩子也会在开启的状态下进行注册，最终呈现的结果，界面定义并控制钩子的调用
二、我们的期望：启发与引导
为了应对需求的频繁变更，在有一定技术积累和追求的前提下，会尽量将与业务无关性的逻辑抽象出来，实现前人种树后人乘凉。但这并不是一件容易做的事，对业务的整体把控、对设计模式的了解和实践抽象的手段缺一不可。虽然会在一开始就立志于做到低耦合，但是对代码的思考不是一蹴而就的。我们希望 fireboom 不仅是提升开发效率的工具，同时也能帮助开发者构建一种新的认知，一种基于声明 API 的开发方式。
同时，我们还期待 fireboom 的抽象能给乐于思考的开发者带来一些启发与引导。比如，原先在开发 API 时，一般的步骤是首先部署 API 网关，然后将 API 添加到网关中并保护它们，而 API 的版本管理通常是通过在 URL 上添加版本标识来实现，诸如”/v1”, “/v2”等。但是，软件开发围绕着 git 进行，为何不能把 API 也交由 git 进行版本管理？当然，做到这一点并不容易，需要将管理身份验证、授权、安全等功能抽象出来，但 fireboom 抽象了网关，允许通过编写一部分的代码来配置和管理 API ，能够以声明性的方式管理 API 。
飞布API-可视化API开发平台 (fireboom.io) 飞布官网地址，欢迎体验
三、声明性 API 依赖性-思考 API 的新方法 多年来，我们一直在使用 NPM 、Maven 或 Go 模块等软件包管理器来管理我们的“代码依赖项”。然而，在管理 API 方面，我们仍然处于石器时代。有时，我们会安装 SDK 来使用 API ，但通常情况下，我们只是使用 API 的 HTTP 请求，API 调用遍布在整个代码库中。最终结果是，我们的代码可能是干净的，但我们完全不知道我们依赖什么 API 。
而单一的统一 API 会是改进架构的好方法。前端直接依赖于多个 API 和服务。在最坏的情况下，N 个 API 可能依赖于 M 服务，而 M 服务依赖于 N 个 API 。每个单独的连接都可以由 API 网关管理，但连接的组成不是。为了解决这一问题，我们可以将多个 API 组合成一个捆绑包，然后将其通过单个接口提供给前端应用程序。在这种情况下，API 依赖项已明确定义，并且可以为整个组合配置身份验证、授权、缓存等策略。这可能并不明显，但能够同时为 RestApi 、Kafka 和 PostgreSQL 的组合定义安全策略，使开发人员的生活变得轻松得多。
如今，内部（微）服务和外部第三方 API 数量相当庞大，几乎每个单独的问题，都有一个对应的 API 可以解决。fireboom 通过统一 API ，可以使这些部分很好地结合在一起，使架构更加简洁，API 管理更加便利。
同时，单一的统一 API 也是促进团队协作的好方法。一般来说，有三类因素常常阻碍团队协作的效率:一是开发者之间存在能力差异；二是对抽象的方式难以一致；三，也是最重要的，实现抽象逻辑的意愿不一，这些都可能造成团队内部各色各样的问题。而统一的 API 会是一种不错的解决方式。
四、案例
-
简单的数据模型字段变更
-
通常的低代码平台再次生成代码时会覆盖自定义的业务逻辑，变更后的字段查找替换也是件麻烦的事。
-
Fireboom 因为是动态注册 API ，生成的代码不会对定义的逻辑造成干扰，同时类型安全也极大的方便了变更字段的查找
-
前后端协作
-
通常情况下，API 变更同时需要更新对应的 swagger 注释或注解，前端需要等待后端部署后才能看到新的接口文档
-
fireboom 在变更 api 中逻辑后，界面点击保存上线后即发布 API 并同时更新接口文档，即时省心
-
为了完成业务需求，引入中间件
-
通常情况下需要添加中间件依赖，中间件配置，使用 sdk 与中间件进行交互，一方面系统复杂性上升，上手也有一定的成本
-
Fireboom 集成了常用的中间件，并进行了可用性的封装，可与 API 声明无缝衔接使用
-
跨数据源查询
-
通常是将两个源的数据分别查出再进行筛选，但无法处理联合查询的逻辑，尤其是微服务盛行的今天，各个服务之间数据源相互独立，目前也有 shardingsphere 这样的解决方案，但是同样有复杂性和上手难的问题
-
Fireboom 提供了跨源查询的能力，并通过缓存查询等手段提高了查询效率，同时有详尽的指导的说明
-
界面操作类型安全
-
在一些实现了动态编译的项目中，编写自定义代码虽然能快速完成需求，但是编写代码时需要小心翼翼的填写变量，填写导致的错误只有等部署运行时才能发现
-
Fireboom 提供了类型安全，即使时在前端界面操作，也如同在开发工具中一样使用自如，快捷提示，变量纠错，大大降低了因书写错误导致的问题
五、反思与不足
-
虽然飞布提供了丰富的自定义钩子机制，但是需要额外启动，同时目前钩子由 typescript 实现，虽然在界面上有语法提示及语义校验，但同时也有一定的学习成本，对于不熟悉 typescript 的开发者可能不是一个很好的消息，后续规划中将使用多种语言实现钩子的能力，提升不同语言开发者的使用体验和意愿。
-
有一些需要深入探索的功能缺少适当的指引，接入的身份验证需要在授权成功后自定义实现根据 UserId 获取角色列表的逻辑，但权限管理中新建角色时没有引导用户实现查询新角色的逻辑
-
缺少对钩子执行流程的追踪，无法直观展现请求生命周期经历过哪些钩子节点。
