# Gable 是怎么工作的？
# Web 客户端
首先，用户可以直接点击链接 https://advancedproductivity.github.io/GablePreview/ (opens new window)
径直体验 Gable 的客户端（也是web端），因为我们很穷，没钱买服务器；
就把Gable 打包部署到了Github上，当然这会导致访问Github 有困难的用户难以访问访问我们的产品。
在大家打开Gable 的客户端之后，就可以进行 Http 接口的测试；
当然，现在 Gable 还仅仅只支持Http 的 API。
当大家点击Send 按钮，即可执行一个 Http 请求
大家可以发现一个有意思的点，就是当我点击 Send 按钮时，对 Http 接口的调用是从客户端浏览器发起的。
Gable 这样设计，主要是为了解决 当我在客户端测试本机开发的 localhost 上的接口时，远程服务器访问不了 localhost 的问题。
其实，还有一个很有意思的点。上面的链接，用户点开就可以进行测试 Http 接口，创建集合等操作，再次刷新浏览器数据都还在？
在没有连接 Gable 服务端时， Gable 客户端是把所有数据都保存在浏览器的 indexDb 中。
因为再没有连接 Gable 服务端的时候，默认是假设不支持协作的功能的，只能算作个人使用的小工具。
当我们有了协作的场景，也就是团队中的成员共享接口数据，以及接口的状态。
就需要先部署一套Gable的服务端，然后在配置一下 Gable服务端的地址，即可将数据保存在远程服务器上。
点击应用即可。如果团队成员均设置相同的地址，大家即可共享一套数据，而数据是由团队自己保存的。
观察一下上面的设置界面，会发现旁边还有一个 API 代理设置的配置：
可以在客户端 设置一个 执行 API 接口的代理服务器。
Gable 的后端服务本身即可作为 这样的代理服务器。
如果设置了这个地址，Http请求的发起就由该代理服务器执行。
与从浏览器上发起请求不同，浏览器发起的请求是基于 浏览器的 Fetch Api 实现的，有很大概率遇到跨域问题。
而如果设置了代理服务器之后，即可解决该跨域问题。
建议在开发的电脑安装启动代理服务器的 jar 包，这样可以执行本地localhost的请求。
# Electron 客户端
Gable 还开发了基于 Electron 的客户端版本的实现，其界面操作逻辑与 web 客户端一模一样。
但是有一点不同，web 客户端在没有连接后端服务时是将数据保存在 indexDb中，
而 electron 客户端将数据保存在 sqlite 中（数据库的db文件存在用户路径下.gable文件夹下，名database.sqlite）。
# 雄心壮志
Gable 是一款开源的 API 协作工具，我们的目标是做出一款全世界最好用的 API 协作工具。
# 该怎么做？
什么样的工具才能称得上是全世界最好用呢？我们认为他应该满足以下特点:
# 高效率
我们认为，API本质是一个团队的资产，既然是资产，只有其高效运转才能不断产生价值。
而API协作这个场景，本质是团队成员合力作战，使用工具最根本的就是为了提高效率。
所以从这一点出发，给团队提效是协作工具的使命。
# 用户体验
尽管现在市面上有些产品的用户体验已经比较细腻完善。
但是在切入到协作的场景时， 各种协作的体验还是不够好，Gable要有更好的协作体验。
# 安全/隐私
我们认为，API 已经属于企业中比较深层的隐私，
大部分严肃的企业应该不愿意且不期望自己的API接口中的字段存在第三方公司中。
# 开源
开源产品是有魅力的，我们做开源不仅仅是把代码放在一个仓库里让用户们自由的下载，
我们还要把这个产品发展过程中的历史脉络以及相关决策公布出来，真正的产品的用户们有权力决策产品的走向。
# 可扩展性
好的产品一定要有可扩展性，有了可扩展性才有用户自由施展的空间，
最简单的场景如：集成 Jenkins 这样的工具中。
# 性能
好产品用起来应该是流畅的，这就要求产品的性能要好。
任何学过计算机的人都知道，性能是货币，但是市场上的其它产品太不会精打细算了。
以至于在协作的场景中不够流畅。
# 价格
应该免费
# Gable 是怎么做的？
# 用户体验上
Gable 会在一定程度上学习市面上已有产品好的设计。
我们对 用户体验 非常重视，我们对自己的要求是死磕用户体验。
# 安全/隐私
Gable 是开源的，所有的数据都保存客户端上，我们不会保存用户的数据。
我们仅仅会用Google Analysis 统计用户流量
# 性能
Gable 后台服务依托于 Java 技术栈，可以轻松扩展成一个微服务集群。
从这一点来说，Gable的上限是比市场上的竞品要高的。
起步 →