DEV Community: Bohdan

How to integrate AI-driven message generation with Cloudflare services: A step-by-step guide

Bohdan — Sun, 07 Dec 2025 21:33:07 +0000

In this guide, I’ll walk through how I implemented an AI-driven message generator for rental requests using Cloudflare Workers AI, TanStack Start, and Llama 3.1.

My implementation leverages a modern edge-first stack:

Cloudflare Workers AI: Provides serverless access to open-source models (specifically @cf/meta/llama-3.1-8b-instruct-fast).
TanStack Start: Used for the full-stack application, utilizing createServerFn for seamless server-side logic.
Hyperdrive (PostgreSQL): Fetches real-time context (user profiles, rental details) to ground the AI's generation.

I created a lightweight wrapper to interact with Cloudflare's AI REST API. This handles authentication and request formatting.

import { env } from "cloudflare:workers";

export const runLLama = async (
  input: {
    max_tokens?: number;
    messages: { role: string; content: string }[];
    // ... validation types
  },
  model: string = "llama-3.1-8b-instruct-fast",
) => {
  const url = `https://api.cloudflare.com/client/v4/accounts/${env.CLOUDFLARE_ACCOUNT_ID}/ai/run/@cf/meta/${model}`;

  const response = await fetch(url, {
    headers: {
      accept: "application/json",
      Authorization: `Bearer ${env.CLOUDFLARE_TOKEN}`, // Secure token handling
      "Content-Type": "application/json",
    },
    method: "POST",
    body: JSON.stringify(input),
  });

  const data = (await response.json()) as LLamaResponse;
  return data.result.response;
};

The server function orchestrates the entire process. Instead of asking the AI to simply "write a message," I provide it with rich context fetched from the project database.

This function performs three key steps:

Validates Input: Ensures I have a valid requestId and userId.
Fetches Context: Retrieves the specific rental request and user profile from the database.
Prompt Engineering: Constructs a detailed prompt ensuring the model follows a strict format.

export const generateMessageServerFn = createServerFn({ method: "POST" })
  .inputValidator(...) // Validate inputs
  .handler(async ({ data, context }): Promise<GeneratedMessage> => {
    // 1. Fetch Request & Profile Data
    const requestData = await getRentalRequestWithProfile(
      context.sql,
      data.requestId,
      data.userId,
    );

    // 2. Build Human-Readable Context Strings
    const occupantsText = [
      `${request.adults} adult${request.adults > 1 ? "s" : ""}`,
      // ... helps model understand composition (adults, children, pets)
    ].join(", ");

    // 3. Construct the Prompt
    const userPrompt = `Generate a professional and friendly introductory message...

    Guest Information:
    - Name: ${profile.first_name} ${profile.last_name}
    - Employment: ${profile.employment}

    Rental Request Details:
    - Destination: ${city_name}, ${country_name}
    - Duration: ${request.term_length} months
    - Occupants: ${occupantsText}

    Format your response EXACTLY as follows:
    [Your title here]
    ---
    [Your body text here]
    `;

    // 4. Call the AI
    const response = await runLLama({
      max_tokens: 512,
      messages: [
        {
          role: "system",
          content: "You are a professional rental message writer...",
        },
        { role: "user", content: userPrompt },
      ],
    });

    // 5. Parse the Response
    const [rawTitle, rawBody] = response.split("---\n");
    return {
      title: rawTitle.replace(/\*/g, "").trim(),
      body: rawBody.trim(),
    };
  });

One of the trickiest parts of working with LLMs is ensuring the output is easy to parse programmatically without over-engineering it with complex JSON schemas.

I opted for a simple, robust approach by forcing a delimiter in the prompt (---). Here is how I process the raw text response:

// 5. Parse the Response
const [rawTitle, rawBody] = response.split("---\n");

return {
  // Remove any standard Markdown bold syntax (**) that models often add to titles
  title: rawTitle.replace(/\*/g, "").trim(), 
  body: rawBody.trim(),
};

Why I did this:

split("---\n"): In the prompt, I explicitly told Llama to separate the title and the body with ---. This allows me to reliably split the single string response into two distinct parts: the headline and the message content.
replace(/\*/g, ""): LLMs have a strong tendency to "bold" titles using Markdown (e.g., **Subject: Hello**). Since I render the title in my own UI component, which already handles styling, I use this regex to strip out those asterisk characters, ensuring I get clean, raw text.

Why This Approach Works

Low Latency: By using Cloudflare's edge network and the "fast" variant of Llama 3.1, I achieved minimal response times.
Structured Output: Prompting the model to use specific delimiters (e.g., ---) allows me to easily parse the title and body separately, maintaining a clean UI/UX.
Privacy & Security: Authentication tokens are kept server-side (accessed via env), and user data is processed securely within the request lifecycle.

Build your own tunnel in Rust: Expose local sites to the Web

Bohdan — Sat, 06 Dec 2025 21:48:42 +0000

The Sidecar pattern is supported by Tauri to allow applications to leverage external binaries written in other languages (Go, Python, C++) or to utilize closed-source tools.

The cloudflared executable is included in the application's distribution resources. To support cross-platform deployment, multiple versions of the binary are bundled, and Tauri's resource manager resolves the appropriate binary at runtime based on the host architecture.

When the Spot Serve invokes cloudflared tunnel --url http://localhost:8080, the following sequence occurs:

Transport Negotiation: cloudflared initiates an outbound connection to Cloudflare's edge network (Argo). By default, it attempts to use the QUIC protocol (based on UDP) for its performance benefits (reduced latency, congestion control). If QUIC fails (e.g., due to strict UDP firewalls), it falls back to HTTP/2 over TCP.
Authentication: For "Quick Tunnels" (TryCloudflare), no pre-authentication is required. The edge network assigns a temporary, random DNS record under trycloudflare.com.
Tunnel Establishment: A persistent session is created. Cloudflare's edge acts as the ingress point.
Reverse Proxying:

Ingress: A user makes an HTTPS request to https://random-name.trycloudflare.com.
Routing: Cloudflare terminates the TLS at the edge, inspects the Host header, and routes the request into the established tunnel connection.
Egress: cloudflared receives the request via the tunnel protocol (Capsule), reconstructs it, and forwards it to localhost:8080.
Response: The local server's response follows the reverse path.

This mechanism completely bypasses the need for inbound firewall rules, as the connection is strictly outbound.

Code Walkthrough

Defining the Sidecar Configuration

In the tauri.conf.json file, the external binary is registered. This tells the bundler to include the binary in the final build artifact.

{
  "tauri": {
    "bundle": {
      "externalBin": [
        "binaries/cloudflared"
      ]
    },
    "allowlist": {
      "shell": {
        "all": false,
        "execute": true,
        "sidecar": true
      }
    }
  }
}

This configuration necessitates that the binaries (e.g., cloudflared-x86_64-unknown-linux-gnu) exist in the src-tauri/binaries directory.

The core logic resides in a Rust command module. We must handle the asynchronous spawning of the process and the non-blocking reading of its output streams.

First, we define a structure to hold the active child process. Since Tauri commands are stateless functions, we use tauri::State to manage persistence across calls.

use std::sync::Mutex;
use tauri::command;
use tauri::api::process::{Command, CommandEvent};

pub struct TunnelState {
    // Mutex to safely share the process handle across threads
    pub child_process: Mutex<Option<tauri::api::process::CommandChild>>,
}

impl Default for TunnelState {
    fn default() -> Self {
        Self {
            child_process: Mutex::new(None),
        }
    }
}

Spawning the Tunnel

The start_tunnel function orchestrates the sidecar. Note the use of Command::new_sidecar which handles the path resolution automatically.

#[command]
pub fn start_tunnel(
    app_handle: tauri::AppHandle,
    port: u16,
    state: tauri::State<TunnelState>,
) -> Result<(), String> {
    let mut state_guard = state.child_process.lock().map_err(|_| "Failed to lock state")?;

    if state_guard.is_some() {
        return Err("Tunnel is already running".into());
    }

    // Configure the sidecar command: cloudflared tunnel --url http://localhost:PORT
    let (mut rx, child) = Command::new_sidecar("cloudflared")
       .map_err(|e| format!("Failed to create sidecar command: {}", e))?
       .args(&["tunnel", "--url", &format!("http://localhost:{}", port)])
       .spawn()
       .map_err(|e| format!("Failed to spawn sidecar: {}", e))?;

    // Store the child handle for later termination
    *state_guard = Some(child);

    // Spawn an async task to listen to stdout/stderr events
    tauri::async_runtime::spawn(async move {
        // Regex to find the TryCloudflare URL
        // Pattern matches: https://[random-subdomain].trycloudflare.com
        let url_regex = regex::Regex::new(r"https://[a-zA-Z0-9-]+\.trycloudflare\.com").unwrap();

        while let Some(event) = rx.recv().await {
            match event {
                CommandEvent::Stderr(line) | CommandEvent::Stdout(line) => {
                    // Log the raw output for debugging
                    println!("[cloudflared]: {}", line);

                    // Check for the URL
                    if let Some(mat) = url_regex.find(&line) {
                        let public_url = mat.as_str().to_string();
                        println!("Tunnel Established: {}", public_url);

                        // Emit the URL back to the frontend
                        app_handle.emit_all("tunnel-url", public_url).unwrap();
                    }
                }
                CommandEvent::Terminated(payload) => {
                    println!("Tunnel terminated: {:?}", payload);
                    break;
                }
                _ => {}
            }
        }
    });

    Ok(())
}

Stopping the tunnel is as critical as starting it. If the user closes the app, the cloudflared process must die.

#[command]
pub fn stop_tunnel(state: tauri::State<TunnelState>) -> Result<(), String> {
    let mut state_guard = state.child_process.lock().map_err(|_| "Failed to lock state")?;

    if let Some(child) = state_guard.take() {
        child.kill().map_err(|e| format!("Failed to kill process: {}", e))?;
    }
    Ok(())
}

Crucially, in a production app, this logic should also be hooked into the application's global WindowEvent::Destroyed or exit handler to prevent zombie processes.

Repository: https://github.com/explicit-logic/spot-serve-gui

How to push updates to the Salesforce production environment

Bohdan — Sat, 06 Dec 2025 16:33:20 +0000

Apex API programming

Apex is a proprietary, object-oriented programming language used by Salesforce developers to execute flow and transaction control statements on the Salesforce platform. It is a powerful, strongly-typed language that looks and behaves like Java.

🛠️ Setting up your environment

Before you can program or deploy, you need to connect your local development environment (Visual Studio Code) to your Salesforce Org.

Watch: How to Connect VS Code to Salesforce Org This video provides a step-by-step guide on authorizing an org and setting up your project.

How to Connect VS Code to Salesforce Org

💻 Apex API Programming

Apex allows developers to:

Implement complex business logic: Custom validations and transaction control.
Create custom Web Services: Expose REST or SOAP endpoints.
Write Triggers: Execute code on database events (insert, update, delete).

For example, a developer might create a REST service using the @RestResource annotation to enable a web application to retrieve and update a customer's service requests quickly.

🚀 How to deploy updates to the Salesforce Production Environment

Deploying updates involves moving metadata from a lower environment (Sandbox) to Production. While you can deploy an entire project, developers often need to deploy specific files to save time and reduce risk.

Use the following command to deploy specific Apex classes within your project:

sf deploy metadata -m "ApexClass:ContactManager" -m "ApexClass:ContactManagerTest" --test-level RunSpecifiedTests --tests ContactManagerTest

Here is the breakdown of what this command does:

sf deploy metadata: This initiates the deployment process focusing on specific metadata components rather than the whole source directory.
-m "ApexClass:ContactManager": The -m flag stands for Metadata. This tells the CLI to only deploy the Apex Class file named "ContactManager".
-m "ApexClass:ContactManagerTest": We use the flag again to include the corresponding Test Class. It is best practice to always deploy the code and its test together.
--test-level RunSpecifiedTests: This is a crucial efficiency flag. By default, production deployments run all local tests. This flag tells Salesforce: "Do not run every test in the system; only run the ones I list."
--tests ContactManagerTest: This explicitly lists the test class to execute. If this test passes (and covers enough lines of code), the deployment succeeds.

Why use this? If your organization has thousands of tests that take 2 hours to run, using RunSpecifiedTests allows you to deploy a hotfix in minutes by only validating the relevant code.

📝 Code Examples

Below are examples of the classes referenced in the command above.

The REST Resource Class (ContactManager.cls)

This class uses the @RestResource annotation to define the endpoint URL. It includes a GET method to retrieve data and a POST method to create new records.

@RestResource(urlMapping='/Contacts/*')
global with sharing class ContactManager {

    // HTTP GET: Retrieve a Contact by ID from the URL
    // Endpoint: https://your-instance.salesforce.com/services/apexrest/Contacts/<ContactId>
    @HttpGet
    global static Contact getContactById() {
        RestRequest req = RestContext.request;

        // Grab the contactId from the end of the URL
        String contactId = req.requestURI.substring(req.requestURI.lastIndexOf('/')+1);

        Contact result = [SELECT Id, Name, Email, Phone FROM Contact WHERE Id = :contactId];
        return result;
    }

    // HTTP POST: Create a new Contact
    // Endpoint: https://your-instance.salesforce.com/services/apexrest/Contacts/
    @HttpPost
    global static ID createContact(String lastName, String firstName, String email, String phone) {
        Contact thisContact = new Contact(
            LastName = lastName,
            FirstName = firstName,
            Email = email,
            Phone = phone
        );
        insert thisContact;
        return thisContact.Id;
    }
}

The Test Class (ContactManagerTest.cls)

Testing REST services in Apex requires a specific step: mocking the RestContext. You must manually construct the Request and Response objects within the test method so the code has a context to run against.

@isTest
private class ContactManagerTest {

    @testSetup
    static void makeData() {
        Contact c = new Contact(LastName='Test', FirstName='Unit', Email='test@example.com');
        insert c;
    }

    @isTest
    static void testGetContactById() {
        // 1. Query the record created in testSetup
        Contact c = [SELECT Id FROM Contact LIMIT 1];

        // 2. Set up the RestContext
        RestRequest req = new RestRequest(); 
        RestResponse res = new RestResponse();

        // Simulate the URL structure defined in the main class
        req.requestURI = '/services/apexrest/Contacts/' + c.Id;
        req.httpMethod = 'GET';

        // Assign the mock request to the context
        RestContext.request = req;
        RestContext.response = res;

        // 3. Call the method
        Test.startTest();
        Contact result = ContactManager.getContactById();
        Test.stopTest();

        // 4. Assertions
        System.assert(result != null);
        System.assertEquals('Test', result.LastName);
    }

    @isTest
    static void testCreateContact() {
        Test.startTest();
        // Call the POST method directly
        ID thisContactId = ContactManager.createContact('Doe', 'John', 'john.doe@example.com', '555-1234');
        Test.stopTest();

        // Verify record exists
        System.assert(thisContactId != null);
        Contact c = [SELECT LastName FROM Contact WHERE Id = :thisContactId];
        System.assertEquals('Doe', c.LastName);
    }
}

Key Concepts in this Example

@RestResource(urlMapping='/Contacts/*'): This exposes the class at the base URL /services/apexrest/Contacts/.
global: Methods exposed as Web Services must be defined as global.
RestContext: A system class that allows your code to access the incoming HTTP Request (RestContext.request) and the outgoing Response (RestContext.response).
Dynamic ID Parsing: In the GET method, we parse the URL to find the ID (substring(req.requestURI.lastIndexOf('/')+1)). This mimics standard REST behavior (e.g., GET /Contacts/003xxxxxxxxxxxx).

Summary

Developing on Salesforce requires a dual mastery: Apex API programming for crafting robust, custom business logic and effective deployment strategies for moving those solutions safely to the Production environment.

Key Takeaways for Success

Code Quality is Paramount: Always adhere to Salesforce best practices, especially writing bulkified code to handle large data volumes efficiently.
Testing is Non-Negotiable: Deployment hinges on your Apex Test Classes. Achieving the minimum 75% code coverage is mandatory for Production deployment, but striving for 100% ensures stability.
Embrace the CLI: Using the Salesforce CLI (sf) for targeted, automated deployments (like using --test-level RunSpecifiedTests) offers speed and reliability far superior to traditional Change Sets.