Show HN: Rethinknig Serverless – Services, Observers, and Actors Now Available

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.

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.

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?

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.

Think of Services as the foundation of a three-pillar approach to modern serverless development:

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

Let’s dive into how Services can be used to make your life easier.

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.

Public Services

// raindrop.manifest service "my-api" { domain { cname = "my-unique-service" } }

When deployed, this service becomes accessible at my-unique-service.<org-id>.lmapp.run. Perfect for APIs, webhooks, and any user-facing functionality.

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.

This is service binding in action: efficient, secure communication between your services without the networking overhead.

Internal Services

// raindrop.manifest service "my-api" {}

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:

// 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; } }

// 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"); } }

Tech Blog - Services: https://liquidmetal.ai/casesAndBlogs/services/ Tech Docs - https://docs.liquidmetal.ai/reference/services/ Sign up for our free tier - https://raindrop.run/