最新

Hi HN， 我正在测试一个想法：做一个类似Fragrantica的数据库，但针对手表。 与炒作评论或规格参数不同，手表将根据实际因素进行评分，例如性价比、耐用性、舒适度和长期精准度。 这只是一个非常早期的MVP（主要是一个着陆页），用于验证这个想法是否有用。 我非常感谢诚实的反馈——缺少什么，哪些感觉是多余的，或者你是否会使用类似这样的东西。

使用无服务器架构，选择非常有限，而且这项技术被牢牢锁定。虽然某些部分可以移植，但大部分不行。我通过 WebSocket 使用二进制协议（Protobuf）。是的，它比在较低层（如 TCP）运行的本地隧道服务要慢，但对于大多数情况来说，它已经足够快了。 扩展是一个主要的挑战。大多数无服务器计算引擎依赖于内部负载均衡器，并且所有实例都是短暂的。这意味着实例间的通信是不可能的。可以通过消息总线（如 Pub/Sub）来实现扩展，但这又引入了另一个问题。发布到主题的请求和响应会在所有活动实例中复制，效率低下。 其他令人烦恼的限制是，计算进程绑定到一个请求，并在请求完成后立即结束。另一个是需要解决由实例的短暂性引起的订阅泄漏问题（我真的讨厌这一点）。 缺点： * 扩展效率低下。 * WebSocket 是有状态的，这违背了无服务器架构的成本优化目的。如果客户端保持连接，成本可能会超过运行专用服务器的成本。 * 协议和平台选项有限。 * 严重的厂商锁定。 优点： * 性能对于大多数用例来说足够好。 * 扩展和基础设施完全托管。 * 不使用则无成本，同时服务保持可用。 * 少量使用通常是免费的，因为大多数云提供商都提供免费套餐。 我认为将其构建为 SaaS 是一个坏主意。它不会降低成本，实际上还会增加成本，并且增加了显著的复杂性。我假设，在今天的市场上，将其作为 SaaS 运行很可能无法盈利。 话虽如此，你认为任何组织会对开源版本感兴趣吗？它是可扩展的，除了初始设置时间外，运行成本为零，如果他们能够正确管理网络访问，则可以更安全。我甚至不确定是否有人愿意为此支付少量费用。 也许我正在构建垃圾。我在这里提问是为了找出它是否可能成为某人的宝藏。