Workers Rpc
You set up workers rpc by linking two serverless functions with a service binding. This lets one worker call methods on another worker without public network hops. Teams often group many backend tasks into shared worker services for fast internal calls. Still, broad bindings let any caller worker run every public method on the receiver. If one edge function gets compromised, an attacker can call sensitive database routines. How workers rpc works in your architecture Traditional serverless app
Rpc: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up workers rpc by linking two serverless functions with a service binding. This lets one worker call methods on another worker without public network hops. Teams often group many backend tasks into shared worker services for fast internal calls. Still, broad bindings let any caller worker run every public method on the receiver. If one edge function gets compromised, an attacker can call sensitive database routines.
How workers rpc works in your architecture
Traditional serverless apps talk to each other over public HTTP endpoints. Each request leaves the runtime, crosses the network, and parses text payloads again. With workers rpc, the platform links the caller and the receiver inside the same network. You define a binding in your project settings to link the two apps. The receiver worker exports a base class that holds your custom methods. The caller worker uses the binding object to invoke those methods directly. The runtime passes structured data types, streams, and object references between the two functions. You do not need to write custom serialization logic or parse JSON strings. Both workers often run in the same thread or on the same physical machine. This design cuts out network latency and removes public endpoint management for internal tools. Teams use this pattern to split big apps into smaller, focused microservices.
What native service bindings solve and what they miss
Native service bindings solve the problem of slow and public internal network calls. You do not need to expose internal worker endpoints to the open internet. You also avoid managing static API keys between your own frontend and backend functions. The platform checks the binding link before it lets one worker talk to another. Still, a service binding only controls which worker can reach another worker. It does not check what individual requests or queries do once the call starts. Any team member who can deploy the caller worker gains full reach. They can invoke every exported method on the target worker without extra checks. Native bindings also do not inspect database queries triggered by those remote calls. If a worker queries a database, the binding will not mask emails or card numbers. You also lack a unified audit log that links human users to backend queries. When engineers debug live systems, broad worker roles leave production data exposed to mistakes.
Securing backend resources behind serverless functions
Serverless functions need strict controls when they talk to core databases and internal systems. Teams must separate simple service links from deep data permissions and query checks. First, split large receiver workers into smaller services with narrow, specific tasks. Do not put admin methods and public read methods in the same exported class. Second, pass clear caller context with each method call so backends can check rules. Third, look closely at how your workers talk to databases and cloud resources. A worker often holds a single master key to read and write production data. Every remote call through that worker shares the same high level of database trust. To fix this, teams must inspect commands in flight before they hit the database. You also need automated data masking to rewrite phone numbers and national IDs in results. Good security checks every single query instead of trusting the whole worker binding.
Rpc: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
How does workers rpc differ from standard HTTP requests?
Standard HTTP requests send text data over the network and require manual parsing. RPC calls invoke methods directly over private bindings and pass rich data objects fast.
Do service bindings require public routes or API keys?
No, service bindings connect workers inside the platform runtime without public URLs. The runtime handles the private link, so you do not need static API keys.
Can native bindings filter database queries or mask sensitive data?
No, a service binding only allows one worker to call methods on another worker. It cannot inspect SQL statements or rewrite emails and card numbers in query results.