为什么插件调用一定要通过一个网关？ #1399
-
|
为什么不能直接从本地发请求？或者可选从本地或网关发送请求？ |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 9 replies
-
|
因为大部分插件都跨域了啊，你直接从本地发请求调用都调不通的 |
Beta Was this translation helpful? Give feedback.
-
所以插件网关可以从服务端发请求，直接可以规避跨域问题。
你怎么让 AskMyPDF 这个插件给你的部署版本域名去开前端跨域？发邮件吗？请考虑下现实可行性。 此外，比如 Search Engine 这样的插件，需要用户自己配置相应的 api key 的。之前又有很多用户问怎么直接部署时候把 key 配置进去（#508 ）。 从后端发的话就可以安全地把这个apikey注入进去，而前端请求就无法实现这个需求。（总不至于把后端配置的 apikey 返回给前端吧？） |
Beta Was this translation helpful? Give feedback.
-
为什么要从本地发送请求？网关服务器也是有计算开销的。例如，Vercel 虽然提供免费的边缘计算，但是请求时间等具有限制。其它非免费的更是按照CPU时间严格收费。
为什么不能部署的时候配置用不用自带网关请求插件？ |
Beta Was this translation helpful? Give feedback.
-
你是不是实现链路理解错了？插件网关为啥会发请求到自己呢？ 现在的实现请求链路是下面这样的： 如果直接从浏览器端发请求到插件服务端，那么就是 a.com -> b.com ，这就会有跨域问题了呀。而 a.com -> a.com/api/plugin/Gateway -> b.com 这样就中转一道服务端就没跨域问题了。 根据我们实际测试的情况，现在大部分社区插件的服务端都不支持跨域调用。如果所有请求都默认走浏览器端，那就意味着大部分插件无法开箱即用，用户一调就报错，肯定不行的。 |
Beta Was this translation helpful? Give feedback.
-
其实光是跨域问题就足够让我选型服务端了，至于客户端是否可行这个点，目前我觉得是不可行的。 |
Beta Was this translation helpful? Give feedback.
-
懂了，就是说网关因为是在node环境下运行的所以没有跨域问题。
这个我不太清楚。我的简单的想法就是 插件=API请求，API请求=客户端完全胜任。你是指有一些复杂的结构解析需要node库吗？如果这个复杂得不能在浏览器跑，能不能让简单的在浏览器跑、复杂的在网关跑？
我提的问题可能涉及到了整体架构的中断性变更，所以必须先讨论好了，不能盲目PR
之所以提出这个请求，是因为我调的API在现有情况下在Vercel里会超时，所以没法做成插件。 |
Beta Was this translation helpful? Give feedback.
-
因为 GPT 要识别 api 的入参结构，所以我们需要给定一个 manifest 来描述这个 api （也就是 Function call 的 json schema）。我们做插件一期的时候，使用的是和 function call 一样的json schema 入参： {
"api": [
{
"url": "http://localhost:3400/api/clothes",
"name": "recommendClothes",
"description": "根据用户的心情，给用户推荐他有的衣服",
"parameters": {
"properties": {
"mood": {
"description": "用户当前的心情，可选值有：开心（happy）, 难过（sad）,生气 （anger）,害怕（fear）,惊喜（ surprise）,厌恶 （disgust）",
"enums": ["happy", "sad", "anger", "fear", "surprise", "disgust"],
"type": "string"
},
"gender": {
"type": "string",
"enum": ["man", "woman"],
"description": "对话用户的性别，需要询问用户后才知道这个信息"
}
},
"required": ["mood", "gender"],
"type": "object"
}
}
]
}如果所有插件都是用这种模式，那么其实是可以在浏览器端去发起请求的。 但是事实上，ChatGPT 的插件，并没有使用这种简单的描述方案，而是采用了 openapi 的 schema （如果你不了解 openapi，可以在这里了解下），一个示例如下： {
"openapi": "3.0.0",
"info": {
"title": "Weather API",
"version": "1.0.0"
},
"paths": {
"/api/weather": {
"get": {
"summary": "Get current weather information",
"operationId": "checkWeatherUsingGET",
"parameters": [
{
"name": "location",
"in": "query",
"required": true,
"description": "Location for which to retrieve weather information.",
"schema": {
"type": "string"
}
}
],
"responses": {
"200": {
"description": "Current weather information",
"content": {
"application/json": {
"schema": {
"type": "object",
"properties": {
"location": {
"type": "object",
"properties": {
"name": {
"type": "string"
},
"region": {
"type": "string"
},
"country": {
"type": "string"
},
"lat": {
"type": "number"
},
"lon": {
"type": "number"
},
"tz_id": {
"type": "string"
},
"localtime_epoch": {
"type": "integer"
},
"localtime": {
"type": "string"
}
}
},
"current": {
"type": "object",
"properties": {
"last_updated": {
"type": "string",
"description": "Local time when the real time data was updated"
},
"last_updated_epoch": {
"type": "integer",
"description": "Local time when the real time data was updated in unix time"
},
"temp_c": {
"type": "number",
"description": "Temperature in celsius"
},
"temp_f": {
"type": "number",
"description": "Temperature in fahrenheit"
},
"is_day": {
"type": "integer",
"description": "1 = Yes 0 = No, Whether to show day condition icon or night icon"
},
"condition": {
"type": "object",
"properties": {
"text": {
"type": "string",
"description": "Weather condition text"
},
"icon": {
"type": "string",
"description": "Weather icon url"
},
"code": {
"type": "integer",
"description": "Weather condition unique code"
}
}
},
"wind_mph": {
"type": "number",
"description": "Wind speed in miles per hour"
},
"wind_kph": {
"type": "number",
"description": "Wind speed in kilometer per hour"
},
"wind_degree": {
"type": "integer",
"description": "Wind direction in degrees"
},
"wind_dir": {
"type": "string",
"description": "Wind direction as 16 point compass, e.g., NSW"
},
"pressure_mb": {
"type": "number",
"description": "Pressure in millibars"
},
"pressure_in": {
"type": "number",
"description": "Pressure in inches"
},
"precip_mm": {
"type": "number",
"description": "Precipitation amount in millimeters"
},
"precip_in": {
"type": "number",
"description": "Precipitation amount in inches"
},
"humidity": {
"type": "integer",
"description": "Humidity as percentage"
},
"cloud": {
"type": "integer",
"description": "Cloud cover as percentage"
},
"feelslike_c": {
"type": "number",
"description": "Feels like temperature in celsius"
},
"feelslike_f": {
"type": "number",
"description": "Feels like temperature in fahrenheit"
},
"vis_km": {
"type": "number",
"description": "Visibility in kilometers"
},
"vis_miles": {
"type": "number",
"description": "Visibility in miles"
},
"uv": {
"type": "number",
"description": "UV Index"
},
"gust_mph": {
"type": "number",
"description": "Wind gust in miles per hour"
},
"gust_kph": {
"type": "number",
"description": "Wind gust in kilometer per hour"
}
}
},
"infoLink": {
"type": "string",
"format": "uri",
"description": "A link to a page with more information about the location's weather in the format https://weathergpt.vercel.app/{location}."
}
}
}
}
}
}
}
}
}
}
}我理解 ChatGPT 使用 openapi 的schema 的目的是为了降低插件的开发成本，因为 openapi 是基本上所有 java、python、go 等典型后端应用都能自动生成的描述文件。这样把一个后端 api 转换成 chatgpt 插件的成本就很低，只需要配置一个 openapi schema 地址，然后写个 prompt 就好了。 从插件生态的丰富度来讲，兼容 ChatGPT 的插件是有意义的，所以我们在三期做了 openapi schema 的兼容实现，这样就可以直接在 LobeChat 里跑 ChatGPT 现有的插件。 但是，由于 gpt 的接口层面的 Function call 需要的 jsonschema 和 openapi 是不完全一致的，所以我们接入 openapi 的过程中，核心需要两个东西：
|
Beta Was this translation helpful? Give feedback.
-
本地文件可能不行，因为浏览器不支持直接读本地文件，但后续可以做成填内容的方式，并支持用户上传文件（就是现在置灰的那个可视化配置 tab 的地方）。 这个点我有记录在插件四期里：#1310
其实如果你只是单纯不经过网关，我们现在是有一种插件模式就是支持的： standalone 类型插件 ，这种插件就是直接唤起一个iframe，然后所有请求都是你在这个 iframe 里管。你可以把这个iframe 当成一个独立应用来实现，请求啥的你都可以自行决定是客户端发还是服务端发，灵活度很高。比如我们做的 Midjourney 插件就是这样，你可以看看: https://github.com/lobehub/lobe-midjourney-webui
这个问题我其实也有遇到，后续我会想想解决方案。vercel 的 node 网关只支持 10s 非常短很蛋疼（付费版倒是可以到1分钟），如果后续能改造成 edge runtime 其实会好一些，edge runtime 的超时时间有 30s。 解决的思路， 一种的确是你说的从浏览器发请求，这个如果是插件开发者来控制的话，其实倒还好实现的。相当于 openapi 那一块不考虑本地请求，只支持服务端请求。 还有一种思路是提供区分同步调用接口和异步调用接口，异步调用接口就额外需要实现相应的轮询功能了，这样其实也能实现。像 mj 插件的绘图效果就是这么搞的。 |
Beta Was this translation helpful? Give feedback.
-
|
如果改成 edge runtime 的话还可以允许通过 Cloudflare Pages 部署，就是不知道那个有没有超时限制 |
Beta Was this translation helpful? Give feedback.
其实光是跨域问题就足够让我选型服务端了，至于客户端是否可行这个点，目前我觉得是不可行的。
原因是我在插件三期里实现的 OpenAPI Schema 兼容，依赖了几个 openapi schema的解析库，这几个库目前都只能在 node里跑，不支持浏览器里跑。要实现在浏览器里跑，得自己写整个openapi 的schema 解析，这个我是绝对不会自己去做的。
如果解决了这个问题，倒是可以做到在浏览器里直接运行。但这块的实现又是一个很大成本，我目前没有这方面的规划。如果你有兴趣可以试试看，欢迎PR。