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/
genovalente•1d ago
The Reactive Programming Problem Difficulty in building reactive applications with traditional serverless functions Most applications need to respond to events: files uploaded to storage, messages arriving in queues, data changes triggering downstream processing. Traditional serverless platforms leave you with limited options—polling APIs on timers, setting up complex webhook systems, or building custom event routing infrastructure.
Polling wastes resources and creates delays. Webhooks require managing external endpoints and handling failures. Custom event systems add operational complexity that defeats the purpose of going serverless in the first place.
Introducing Raindrop Observers Observers in Raindrop are powerful components that let you execute code in response to changes in your resources automatically. Think of them as event listeners that trigger when specific conditions are met in your application—no polling, no complex setup, just clean reactive code.
Raindrop Observers event listening reactive capabilites with clean code Observers are the second pillar in Raindrop’s approach to modern serverless development:
Services (Part 1): Efficient serverless functions with built-in communication Observers (this post): React to changes and events automatically Actors (Part 3): Maintain state and coordinate complex workflows Let’s dive into how Observers can be used to make your life easier.