这是一个创建于 518 天前的主题，其中的信息可能已经有所发展或是发生改变。
一、Hooks 无处不在
fireboom 中有大量模版方法的实践，包括认证前后，全局请求前后，当前请求前后的自定义逻辑。
在 java 中，会定义一个接口交由下层实现，上层通过接口类型在 spring 容器中找出所有 bean 实现并依次遍历调用。
而在飞布中，会将定义的 api 动态注册到路由中，同时定义的钩子也会在开启的状态下进行注册，最终呈现的结果，界面定义并控制钩子的调用
二、我们的期望：启发与引导
为了应对需求的频繁变更，在有一定技术积累和追求的前提下，会尽量将与业务无关性的逻辑抽象出来，实现前人种树后人乘凉。但这并不是一件容易做的事，对业务的整体把控、对设计模式的了解和实践抽象的手段缺一不可。虽然会在一开始就立志于做到低耦合，但是对代码的思考不是一蹴而就的。我们希望 fireboom 不仅是提升开发效率的工具，同时也能帮助开发者构建一种新的认知，一种基于声明 API 的开发方式。
同时，我们还期待 fireboom 的抽象能给乐于思考的开发者带来一些启发与引导。比如，原先在开发 API 时，一般的步骤是首先部署 API 网关，然后将 API 添加到网关中并保护它们，而 API 的版本管理通常是通过在 URL 上添加版本标识来实现，诸如”/v1”, “/v2”等。但是，软件开发围绕着 git 进行，为何不能把 API 也交由 git 进行版本管理？当然，做到这一点并不容易，需要将管理身份验证、授权、安全等功能抽象出来，但 fireboom 抽象了网关，允许通过编写一部分的代码来配置和管理 API ，能够以声明性的方式管理 API 。
三、声明性 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 会是一种不错的解决方式。
四、案例
1. 简单的数据模型字段变更
1. 通常的低代码平台再次生成代码时会覆盖自定义的业务逻辑，变更后的字段查找替换也是件麻烦的事。
2. Fireboom 因为是动态注册 API ，生成的代码不会对定义的逻辑造成干扰，同时类型安全也极大的方便了变更字段的查找
2. 前后端协作
1. 通常情况下，API 变更同时需要更新对应的 swagger 注释或注解，前端需要等待后端部署后才能看到新的接口文档
2. fireboom 在变更 api 中逻辑后，界面点击保存上线后即发布 API 并同时更新接口文档，即时省心
3. 为了完成业务需求，引入中间件
1. 通常情况下需要添加中间件依赖，中间件配置，使用 sdk 与中间件进行交互，一方面系统复杂性上升，上手也有一定的成本
2. Fireboom 集成了常用的中间件，并进行了可用性的封装，可与 API 声明无缝衔接使用
4. 跨数据源查询
1. 通常是将两个源的数据分别查出再进行筛选，但无法处理联合查询的逻辑，尤其是微服务盛行的今天，各个服务之间数据源相互独立，目前也有 shardingsphere 这样的解决方案，但是同样有复杂性和上手难的问题
2. Fireboom 提供了跨源查询的能力，并通过缓存查询等手段提高了查询效率，同时有详尽的指导的说明
5. 界面操作类型安全
1. 在一些实现了动态编译的项目中，编写自定义代码虽然能快速完成需求，但是编写代码时需要小心翼翼的填写变量，填写导致的错误只有等部署运行时才能发现
2. Fireboom 提供了类型安全，即使时在前端界面操作，也如同在开发工具中一样使用自如，快捷提示，变量纠错，大大降低了因书写错误导致的问题
五、反思与不足
1. 虽然飞布提供了丰富的自定义钩子机制，但是需要额外启动，同时目前钩子由 typescript 实现，虽然在界面上有语法提示及语义校验，但同时也有一定的学习成本，对于不熟悉 typescript 的开发者可能不是一个很好的消息，后续规划中将使用多种语言实现钩子的能力，提升不同语言开发者的使用体验和意愿。
2. 有一些需要深入探索的功能缺少适当的指引，接入的身份验证需要在授权成功后自定义实现根据 UserId 获取角色列表的逻辑，但权限管理中新建角色时没有引导用户实现查询新角色的逻辑
3. 缺少对钩子执行流程的追踪，无法直观展现请求生命周期经历过哪些钩子节点。
fireboom 中有大量模版方法的实践，包括认证前后，全局请求前后，当前请求前后的自定义逻辑。
在 java 中，会定义一个接口交由下层实现，上层通过接口类型在 spring 容器中找出所有 bean 实现并依次遍历调用。
而在飞布中，会将定义的 api 动态注册到路由中，同时定义的钩子也会在开启的状态下进行注册，最终呈现的结果，界面定义并控制钩子的调用
二、我们的期望：启发与引导
为了应对需求的频繁变更，在有一定技术积累和追求的前提下，会尽量将与业务无关性的逻辑抽象出来，实现前人种树后人乘凉。但这并不是一件容易做的事，对业务的整体把控、对设计模式的了解和实践抽象的手段缺一不可。虽然会在一开始就立志于做到低耦合，但是对代码的思考不是一蹴而就的。我们希望 fireboom 不仅是提升开发效率的工具，同时也能帮助开发者构建一种新的认知，一种基于声明 API 的开发方式。
同时，我们还期待 fireboom 的抽象能给乐于思考的开发者带来一些启发与引导。比如，原先在开发 API 时，一般的步骤是首先部署 API 网关，然后将 API 添加到网关中并保护它们，而 API 的版本管理通常是通过在 URL 上添加版本标识来实现，诸如”/v1”, “/v2”等。但是，软件开发围绕着 git 进行，为何不能把 API 也交由 git 进行版本管理？当然，做到这一点并不容易，需要将管理身份验证、授权、安全等功能抽象出来，但 fireboom 抽象了网关，允许通过编写一部分的代码来配置和管理 API ，能够以声明性的方式管理 API 。
三、声明性 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 会是一种不错的解决方式。
四、案例
1. 简单的数据模型字段变更
1. 通常的低代码平台再次生成代码时会覆盖自定义的业务逻辑，变更后的字段查找替换也是件麻烦的事。
2. Fireboom 因为是动态注册 API ，生成的代码不会对定义的逻辑造成干扰，同时类型安全也极大的方便了变更字段的查找
2. 前后端协作
1. 通常情况下，API 变更同时需要更新对应的 swagger 注释或注解，前端需要等待后端部署后才能看到新的接口文档
2. fireboom 在变更 api 中逻辑后，界面点击保存上线后即发布 API 并同时更新接口文档，即时省心
3. 为了完成业务需求，引入中间件
1. 通常情况下需要添加中间件依赖，中间件配置，使用 sdk 与中间件进行交互，一方面系统复杂性上升，上手也有一定的成本
2. Fireboom 集成了常用的中间件，并进行了可用性的封装，可与 API 声明无缝衔接使用
4. 跨数据源查询
1. 通常是将两个源的数据分别查出再进行筛选，但无法处理联合查询的逻辑，尤其是微服务盛行的今天，各个服务之间数据源相互独立，目前也有 shardingsphere 这样的解决方案，但是同样有复杂性和上手难的问题
2. Fireboom 提供了跨源查询的能力，并通过缓存查询等手段提高了查询效率，同时有详尽的指导的说明
5. 界面操作类型安全
1. 在一些实现了动态编译的项目中，编写自定义代码虽然能快速完成需求，但是编写代码时需要小心翼翼的填写变量，填写导致的错误只有等部署运行时才能发现
2. Fireboom 提供了类型安全，即使时在前端界面操作，也如同在开发工具中一样使用自如，快捷提示，变量纠错，大大降低了因书写错误导致的问题
五、反思与不足
1. 虽然飞布提供了丰富的自定义钩子机制，但是需要额外启动，同时目前钩子由 typescript 实现，虽然在界面上有语法提示及语义校验，但同时也有一定的学习成本，对于不熟悉 typescript 的开发者可能不是一个很好的消息，后续规划中将使用多种语言实现钩子的能力，提升不同语言开发者的使用体验和意愿。
2. 有一些需要深入探索的功能缺少适当的指引，接入的身份验证需要在授权成功后自定义实现根据 UserId 获取角色列表的逻辑，但权限管理中新建角色时没有引导用户实现查询新角色的逻辑
3. 缺少对钩子执行流程的追踪，无法直观展现请求生命周期经历过哪些钩子节点。
 |
1
Blackcat1109501 OP https://www.fireboom.io/
飞布官网链接，欢迎体验 |
 |
2
Dolov 2023-07-19 13:45:22 +08:00
|
Select Language