我可以使用 fs.readFile 代替 fs.readFileSync。我可以改用套接字流吗？

Question

Google API 的 Node.js 示例包含此内容（用于服务器代码）。这是来自 Google 在 GitHub 上的示例，此处为目的而进行了简化：

const audio = {
    content: fs.readFileSync(filename).toString('base64'),
};

const request = {
    audio: audio,
};

return client
    .longRunningRecognize(request)
    .then(
       ...
    })

这让我很吃惊（因为我认为异步是 Node.js 服务器代码的标准）。我想知道我是否可以用fs.readFile 替换它（这是异步版本）。

编辑：以上部分似乎至少部分由简单的“是”回答，谢谢。但我不明白如何修复 base64 部分（并避免内存中有大文件）。

但是，我真正想做的是将带有套接字的文件流式传输到此 API。我可以这样做吗（如果我为如何做足够长的时间而苦恼……）？

编辑：我会很感激这里使用套接字的一些例子。如何流式传输到类似上述结构的内容？

编辑 2：有一个库 socked-io.file，但我不知道如何将其放入上面的 API 接口中。可以吗？

编辑 3：在我拥有该文件的 API 代码中，该文件已经在服务器上，但我想上传该文件。 （很抱歉造成混乱。）

Answer 1

如果您查看了client.longRunningRecognize() 的文档，您会发现request.audio 可以改为包含指向 google 云存储音频文件的 URI。

基于这种方法，您可以选择将fs.createReadStream(filename) 作为上传流式传输到该位置，然后再使用RecognitionAudio#uri 的请求对象调用client.longRunningRecognize() 到流式上传上传的目的地，而不是RecognitionAudio#content文件的 base64 字符串。

这将防止像fs.readFileSync() 那样阻塞事件循环，并且它会避免像fs.readFileSync() 和 fs.readFile() 那样在内存中缓冲整个文件。

似乎将protobuffer 传递给RecognitionAudio#content 将允许您将音频数据直接流式传输到API 请求，但研究这种方法需要更多关于this 工作原理的知识。