Today, we are excited to announce a new feature in Fiberplane’s instrumentation client: support for tracing Cloudflare Service Bindings. Service bindings allow for Worker-to-Worker communication, and tracing them enables better visibility and debugging for distributed systems built on Cloudflare.
Cloudflare Service Bindings
Cloudflare Workers can invoke other Cloudflare Workers in the same network, facilitating the creation of distributed architectures on Cloudflare.
Workers Service Bindings allow for multiple Workers to utilize another Worker’s functionality, like authenticating requests or sending emails.
Decomposing your logic into multiple Workers can therefore reduce code duplication, simplify maintenance, and streamline updates to core parts of your system.
Additionally, when you rely on Service Bindings, certain Workers can remain completely unexposed to the public internet, which gives your application an nice added layer of security.
Simple example use case
Imagine you want to organize a marathon event. To allow athletes to register, you provide a sign-up form on your website.
When an athlete submits the form, their data is stored in a database. An email is then sent to confirm their registration.
Separately, and not as part of the registration process, you offer a newsletter subscription. When an athlete subscribes to the newsletter, their email address is stored in a different database, and they receive a welcome email.
In this scenario, you could have three workers: one for handling the sign-up form, another for managing the newsletter subscription, and then a shared email worker to send emails.
How it works
When one Cloudflare Worker invokes another, the calls remain within the same execution thread. This design ensures that breaking down service logic into multiple Workers does not introduce network latency, making the architecture both flexible and high-performance.
There are two primary ways Workers can communicate using Service Bindings:
- RPC
- HTTP
Bindings are configured in the wrangler.toml file. If you want to learn more about setting up Service Bindings, check out the Cloudflare documentation.
Since the calls occur in the same thread, it’s important to handle them asynchronously.
Otherwise, Worker A might terminate the thread before Worker B has completed its operation. Here is a simple example using rpc:
await c.env.WORKER_EMAIL.send(email, firstName);If the Service Binding is defined in the wrangler.toml file, the Worker can invoke another Worker’s function by using the binding name and the appropriate function from the other Worker.
Developing with multiple Workers
As service distribution increases, so does the complexity of observing and debugging a system. Tracing the full call chain of a request becomes critical to understanding performance and error handling. This is particularly important when dealing with asynchronous background tasks executed by other Workers.
Observing and measuring response times is already an important aspect of local development. It helps you understand your application’s performance and identify bottlenecks.
Example with Fiberplane
Let’s explore how Fiberplane’s instrumentation client can help trace requests between Cloudflare Workers.
In this example, we use Fiberplane’s client to instrument the sign-up Worker, which stores user data in a database and invokes the email Worker to send a confirmation email. With Fiberplane, you can visualize the entire call chain of this request.
In the trace above, we see a sequential execution model where the sign-up Worker first performs database operations and then invokes the email Worker. The total execution time depends on the entire call chain, as shown below.
We can improve the response time by using parallel execution with waitUntil().
app.post("/api/marathon-wait-until", async (c) => { const { firstName, lastName, email, address, distance } = await c.req.json();
//using waitUntil() and invoke email worker via rpc c.executionCtx.waitUntil(c.env.WORKER_EMAIL.send(email, firstName));
await insertData( firstName, lastName, email, address, distance, c.env.DATABASE_URL );
return c.text("Thanks for registering for our Marathon", 200);});Using Fiberplane, we can also visualize the improved execution model:
By adopting waitUntil() for parallel execution, you can reduce user-facing latency while ensuring that background operations are completed efficiently.
Tracing across multiple Workers is therefore important to understand dependencies and visualize the total lifecycle of the thread.
Additionally, Fiberplane’s studio provides detailed information about the Service Binding:
This new feature in Fiberplane’s instrumentation client simplifies tracing between Cloudflare Workers, offering developers better visibility and control over distributed architectures. Explore the example code and start tracing your Cloudflare Workers today!