展示HN：重新思考无服务器架构 – 服务、观察者和参与者现已上线
嘿，HN - 今天我们推出了一个全新的全球可用的无服务器平台，首要考虑的是简洁性和开发者体验。欢迎告诉我们您的想法 - 现在可以免费试用。
传统的无服务器函数就像孤岛。每个函数处理一个请求，完成工作后就忘记一切。如果需要一个函数与另一个函数通信？您就得通过公共互联网进行HTTP调用，管理自己服务之间的身份验证，并在简单的内部操作中处理不必要的网络延迟。
这种架构限制阻碍了复杂应用程序的无服务器采用。如果将单体应用拆分为微服务，意味着每个内部操作都变成了缓慢、不安全的HTTP调用，或者任何更好的服务间通信方式完全依赖于开发者，这样又有什么意义呢？
介绍 Raindrop 服务
Raindrop中的服务是无状态的计算模块，解决了这个根本问题。它们是可以独立工作或直接相互通信的无服务器函数——没有HTTP开销，没有身份验证的麻烦，没有架构上的妥协。
可以将服务视为现代无服务器开发的三大支柱之一：
1. 服务（下方链接）：高效的无服务器函数，内置通信功能
2. 观察者（第二部分）：自动响应变化和事件
3. 执行者（第三部分）：维护状态并协调复杂工作流
让我们深入了解服务如何让您的生活更轻松。
公共服务：您应用的前门
公共服务正是您所期望的——通过唯一的URL访问的无服务器函数。它们处理外部请求，管理身份验证，并作为您应用的入口点。
公共服务
```plaintext
// raindrop.manifest
service "my-api" {
domain {
cname = "my-unique-service"
}
}
```
部署后，该服务将可以在 my-unique-service.<org-id>.lmapp.run 访问。非常适合API、Webhook和任何面向用户的功能。
内部服务：秘密武器
这里的事情变得有趣。内部服务不需要公共URL——它们设计为被应用内的其他服务调用。但与传统的无服务器函数不同，它们可以直接调用，而无需HTTP请求。
这就是服务绑定的实际应用：在您的服务之间实现高效、安全的通信，而无需网络开销。
内部服务
```plaintext
// raindrop.manifest
service "my-api" {}
```
服务绑定：直接的内部通信
当服务相互调用时，魔法就发生了。服务直接调用其他服务的方法，而不是发出HTTP请求。这就像在您的函数之间建立了一个私有的高速网络。以下是公共和内部服务的实际应用：
```javascript
// 服务A（面向公众）
export default class extends Service<Env> {
async fetch(request: Request): Promise<Response> {
// 直接调用内部服务 - 不需要HTTP，不需要URL
const response = await this.env.SERVICE_B.processData({
userId: getUserId(request)
});
return response;
}
}
// 服务B（仅限内部）
export default class extends Service<Env> {
async processData(input: any): Promise<Response> {
// 这里是您的业务逻辑
return new Response("处理成功");
}
}
```
技术博客 - 服务: [https://liquidmetal.ai/casesAndBlogs/services/](https://liquidmetal.ai/casesAndBlogs/services/)
技术文档 - [https://docs.liquidmetal.ai/reference/services/](https://docs.liquidmetal.ai/reference/services/)
注册我们的免费套餐 - [https://raindrop.run/](https://raindrop.run/)
查看原文
Hey HN - Today we launched a new globally available Serverless platform that thinks about simplicity and DX first and foremost. Let us know what you think - try it now for free.<p>Traditional serverless functions are islands. Each function handles a request, does its work, and forgets everything. Need one function to talk to another? You’ll be making HTTP calls over the public internet, managing authentication between your own services, and dealing with unnecessary network latency for simple internal operations.<p>This architectural limitation has held back serverless adoption for complex applications. Why would you break your monolith into microservices if it means every internal operation becomes a slow, insecure HTTP call, and/or any better way of having communications between them is an exercise completely left up to the developer?<p>Introducing Raindrop Services
Services in Raindrop are stateless compute blocks that solve this fundamental problem. They’re serverless functions that can work independently or communicate directly with each other—no HTTP overhead, no authentication headaches, no architectural compromises.<p>Think of Services as the foundation of a three-pillar approach to modern serverless development:<p>Services (this link below): Efficient serverless functions with built-in communication
Observers (Part 2): React to changes and events automatically
Actors (Part 3): Maintain state and coordinate complex workflows<p>Let’s dive into how Services can be used to make your life easier.<p>Public Services: Your Application’s Front Door
Public services are exactly what you’d expect—serverless functions accessible via unique URLs. They handle external requests, manage authentication, and serve as entry points to your application.<p>Public Services<p>// raindrop.manifest
service "my-api" {
domain {
cname = "my-unique-service"
}
}<p>When deployed, this service becomes accessible at my-unique-service.<org-id>.lmapp.run. Perfect for APIs, webhooks, and any user-facing functionality.<p>Internal Services: The Secret Sauce
Here’s where things get interesting. Internal services don’t need public URLs—they’re designed to be called by other services within your application. But unlike traditional serverless functions, they can be invoked directly without HTTP calls.<p>This is service binding in action: efficient, secure communication between your services without the networking overhead.<p>Internal Services<p>// raindrop.manifest
service "my-api" {}<p>Service Bindings: Direct Internal Communication
The magic happens when services call each other. Instead of making HTTP requests, services invoke methods directly on other services. It’s like having a private, high-speed network between your functions. Below are the public and internal services in action:<p>// Service A (public-facing)
export default class extends Service<Env> {
async fetch(request: Request): Promise<Response> {
// Direct call to internal service - no HTTP, no URLs needed
const response = await this.env.SERVICE_B.processData({
userId: getUserId(request)
});
return response;
}
}<p>// Service B (internal-only)
export default class extends Service<Env> {
async processData(input: any): Promise<Response> {
// Your business logic here
return new Response("Processed successfully");
}
}<p>Tech Blog - Services: <a href="https://liquidmetal.ai/casesAndBlogs/services/" rel="nofollow">https://liquidmetal.ai/casesAndBlogs/services/</a>
Tech Docs - <a href="https://docs.liquidmetal.ai/reference/services/" rel="nofollow">https://docs.liquidmetal.ai/reference/services/</a>
Sign up for our free tier - <a href="https://raindrop.run/" rel="nofollow">https://raindrop.run/</a>