Cloudflare Workers Rpc
You set up cloudflare workers rpc by linking two scripts with a service binding. This lets one script call methods on another script without public HTTP traffic. Teams often use this setup to split one large edge app into smaller parts. Still, broad bindings give calling scripts full reach over every exposed class method. A small bug in one script can then trigger unintended actions across your account. How cloudflare workers rpc works at the edge Traditional microservice setups send data ove
Workers Rpc: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up cloudflare workers rpc by linking two scripts with a service binding. This lets one script call methods on another script without public HTTP traffic. Teams often use this setup to split one large edge app into smaller parts. Still, broad bindings give calling scripts full reach over every exposed class method. A small bug in one script can then trigger unintended actions across your account.
How cloudflare workers rpc works at the edge
Traditional microservice setups send data over the public internet using standard web requests. Each request pays a heavy cost in network delay and data parsing time. Edge scripts avoid this cost by running inside the same local host process. When you link two scripts, the platform wires them together in memory.
The target script defines a special entrypoint class with custom methods for your team. The calling script gets a binding object that points right to that target class. Developers call a method on the binding just like a normal local function. The platform passes structured data types, streams, and object references across the boundary.
You can even pass functions or class instances back and forth between scripts. Both scripts stay isolated in their own memory spaces for safety. Yet they talk to each other with almost zero network delay. This makes it easy to build separate scripts for billing, user checks, and mail.
What native service bindings solve and where gaps remain
Native service bindings solve the problem of public network exposure between internal services. Your backend script does not need a public web route to take traffic. Only scripts with an explicit binding in their setup file can call it. This keeps external attackers from hitting your internal helper scripts from the internet.
Still, a service binding only decides which script can talk to another script. It does not check what individual calls or backend queries do in flight. Once a script holds a binding, it can call any public method on it. Also, the target script often holds secret keys to reach core databases.
If a developer logs in to run a local test, they need database keys. Sharing those raw keys across the team creates a big risk for data leaks. Also, native script bindings do not mask sensitive fields in database query results. If a query returns emails, phone numbers, or card numbers, the script gets everything.
Workers Rpc: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Managing backend secrets and database calls from edge scripts
Edge apps rarely live alone without talking to a central database or server. Most target scripts exist to read or write data in a core system. Teams usually store database passwords or API keys as secret variables on the script. Any method on that script can then run queries with full database rights.
When an engineer debugs an edge issue, they often pull those secrets locally. Soon, raw database keys sit on laptops and in local text files. Native account roles control who can deploy a script to the cloud platform. Yet those roles do not audit the exact queries that engineers run during fixes.
To stay safe, teams must separate script deployment rights from live data permissions. You need a clear log of every command that touches your core data stores. You also need a way to mask national IDs or card numbers in results. That way, sensitive fields get rewritten before they reach a developer screen or log.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
How does cloudflare workers rpc differ from standard HTTP bindings?
Standard bindings require you to build and parse web requests and responses by hand. The RPC system lets you call methods directly and pass rich objects in memory.
Do linked edge scripts add extra network delay to an app?
No, linked scripts run on the same machine and talk over fast local memory. You do not pay the time cost of a public network trip between them.
Can a linked script expose our internal database to risk?
Yes, if the target script holds broad database keys and exposes write methods. Any script or user with binding rights can trigger those database queries without checks.