Cloudinary 推荐用法
Posted
技术标签:
【中文标题】Cloudinary 推荐用法【英文标题】:Cloudinary recommended usage 【发布时间】:2020-12-09 12:30:34 【问题描述】:我有一个 Angular / react 客户端和 NodeJS 服务器。 我的客户会将图像上传到他们的个人资料中,我会将它们存储在云端。 好奇这里推荐的路径是什么,因为我可以看到两种方式,每种方式都有优点/缺点
-
我可以将图像从网络发布到我的 NodeJS 服务器,然后再发布到 cloudinary
我可以将图像直接从网络上传到 cloudinary,然后将 URL 从客户端传递给我。
方法 #1 更安全 - 我控制流量/上传 方法 #2 更快 - 文件不会通过我的服务器路由并直接进入 cloudinary
我很感激想法/评论/推荐的用法 - 因为我无法通过 cloudinary 找到任何...
【问题讨论】:
【参考方案1】:这里列出了每种方法的优缺点。
服务器端上传
优点:
在继续上传到 Cloudinary 之前,您可以设置自己的自定义逻辑和验证 您可以轻松地动态应用许多其他优化和转换,而无需针对每个所需的场景预先设置多个未签名的上传预设 如果需要,您可以将资产存储在自己的存储桶中,然后再将其上传到 Cloudinary。缺点:
上传时间更长。资产被上传两次。一次从客户端的浏览器到您的服务器,第二次从您的服务器到 Cloudinary。 浪费您可能需要为托管服务(即 AWS)支付的服务器资源 - 计算、带宽、存储。客户端上传
优点:
正如您所提到的,它更快,因为一旦客户端完成上传资产,上传就完成了,无需从您的服务器再次上传到 Cloudinary。 可选择使用 Cloudinary 的 Upload Widget 快速实施 无论您每天上传 1 次还是 100 万次上传,这对您的服务器都没有影响。您无需关心处理上传队列的瓶颈、扩展您的服务器,当然,您还可以节省此操作的成本。最重要的是,当同时上传时,您客户的用户体验和加载时间不会受到影响。缺点:
您必须使用上传预设进行上传。您不能只是简单地在客户端代码中添加/修改 Cloudinary 的优化和转换参数,除非您签署您的请求。生成签名只能在服务器端完成,这样您就不会公开您的 API 机密。因此,这要求您在实际发送请求之前将每个请求的有效负载发送到您的服务器以取回签名。这导致每个客户端上传都依赖于您的服务器,尽管不必处理更消耗资源的实际上传。您还应该注意,如果您还使用 Admin 或 Search API,则永远不应从客户端执行这些操作,因为这些是需要完整凭据身份验证的管理操作。因此,如果您确实使用它,您将不可避免地需要为它们提供服务器端实现。
总而言之,没有一种方法最终会比另一种更好。这实际上取决于您的用例、需求和偏好。
【讨论】:
以上是关于Cloudinary 推荐用法的主要内容,如果未能解决你的问题,请参考以下文章