Workflows support

[lemarier]

Is there an existing issue for this?

• I have searched the existing issues

Description

Hi guys,

Would be great if we could trigger workflows from workers-rs

Would be even better if we could build workflows with workers-rs at some point as well.

Thanks!

[sidharthachatterjee]

Thank you for opening this. It's on my mind. We're working on prioritising this after we hit some ground for stability. We'll most likely ship this for GA.

[jeastham1993]

@sidharthachatterjee is there any update on this out of interest?

[PeterMHammond]

I just built an entire Workflow in workers-rs using standard Durable Object just because it's not available.
(It is really difficult to get right). Argued with Gemini for a long time about it.

As of the current state of workers-rs and Cloudflare's documentation, there is no direct equivalent to the WorkflowEntrypoint and WorkflowStep API from the TypeScript Cloudflare Workflows within workers-rs.

The way Cloudflare Workflows are defined and executed with the WorkflowEntrypoint class and the step API is a higher-level abstraction that is primarily available in the JavaScript/TypeScript environment of Workers.

In conclusion, while you can indeed use wasm-bindgen to manually create bindings to JavaScript APIs within the Worker environment, directly replicating the WorkflowEntrypoint and WorkflowStep abstraction from TypeScript might be very challenging due to the internal nature of how Workflows are executed. It's more likely that you could use wasm-bindgen to interact with lower-level Workflows management functions (if exposed) or continue to build your workflow logic using Durable Objects as demonstrated earlier.

Which is what I'm doing and this is a real pain to recreate the OOB features of what Workflows offer.
I'm not going back to JavaScript/TypeScript if at all possible.
Looking forward to RUST being a first class citizen in the Cloudflare architecture.

[spigaz]

@PeterMHammond I'm not sure if I have already explained this before to you.

But its not that hard to extend the missing functionality as workers-rs are just a shim over the js/ts implementation.

Most likely if you point Gemini to the documentation and the workers-rs repo, it will guide you in the process.

What might be harder is to get some feedback from Cloudflare.

I'm not sure why, but as people aren't organised and keep moving away, workers-rs is pretty much on hold in practice.

[PeterMHammond]

@PeterMHammond I'm not sure if I have already explained this before to you.
But its not that hard to extend the missing functionality as workers-rs are just a shim over the js/ts implementation.
Most likely if you point Gemini to the documentation and the workers-rs repo, it will guide you in the process.
What might be harder is to get some feedback from Cloudflare.
I'm not sure why, but as people aren't organised and keep moving away, workers-rs is pretty much on hold in practice.

Hi @spigaz, and yes, thank you as you have pointed me to this previously, and I have taken your advise.
I'm just holding out hope that someone at @cloudflare will see what's happening and take it off of hold, as RUST is one of the best ways to build on Cloudflare, IMHO.

That said, based on my research it's not actually possible to create a wrapper shim on the Workflow specifically, as they're doing something very custom with it and the js/ts implementation, something that is serializing it in a special way that you fundamentally can't shim an have a wasm assembly injected into. I may be wrong, but all the AI's were pretty adamant it won't work.

You'd be happy with me as I took your advise and shimmed this out to get to some of the the headers that were not exposed through the workers-rs interface. Took a bit but the tls_client_random was particularly helpful in creating a custom key for users, without needing the random crate.

use serde::Serialize;
use worker::*;
use worker::worker_sys::IncomingRequestCfProperties;
use worker::worker_sys::ext::RequestExt;
use wasm_bindgen::JsCast;

#[derive(Debug)]
pub struct CfExtras {
    inner: IncomingRequestCfProperties,
}

unsafe impl Send for CfExtras {}
unsafe impl Sync for CfExtras {}

impl CfExtras {
    pub fn new(inner: IncomingRequestCfProperties) -> Self {
        Self { inner }
    }    
    
    pub fn tls_client_random(&self) -> Option<String> {
        let js_object = <IncomingRequestCfProperties as AsRef<wasm_bindgen::JsValue>>::as_ref(&self.inner).dyn_ref::<js_sys::Object>()?;
        let property = js_sys::Reflect::get(js_object, &wasm_bindgen::JsValue::from_str("tlsClientRandom")).ok()?;
        
        if property.is_undefined() || property.is_null() {
            return None;
        }
        
        property.as_string()
    }
}

pub trait RequestCfExt {
    fn cf_extras(&self) -> Option<CfExtras>;
}

impl RequestCfExt for Request {
    fn cf_extras(&self) -> Option<CfExtras> {
        self.inner().cf().map(CfExtras::new)
    }
}

#[derive(Serialize)]
pub struct CfInfo {
    pub coordinates: Option<String>,
    pub region: Option<String>,
    pub city: Option<String>,
    pub country: Option<String>,
    pub colo: Option<String>,
    pub timezone: Option<String>,
    pub continent: Option<String>,
    pub asn: Option<u32>,
    pub postal_code: Option<String>,
    pub metro_code: Option<String>,
    pub region_code: Option<String>,
    pub is_eu_country: Option<bool>,
    pub request_priority: Option<String>,
    pub http_protocol: Option<String>,
    pub tls_version: Option<String>,
    pub tls_cipher: Option<String>,
    pub tls_client_random: Option<String>,
    pub as_organization: Option<String>,
}

impl From<&Cf> for CfInfo {
    fn from(cf: &Cf) -> Self {
        Self {
            coordinates: cf.coordinates().map(|c| format!("{:?}", c)),
            region: cf.region(),
            city: cf.city(),
            country: cf.country(),
            colo: Some(cf.colo()),
            timezone: Some(cf.timezone_name()),
            continent: cf.continent(),
            asn: Some(cf.asn()),
            postal_code: cf.postal_code(),
            metro_code: cf.metro_code(),
            region_code: cf.region_code(),
            is_eu_country: Some(cf.is_eu_country()),
            request_priority: None,
            http_protocol: Some(cf.http_protocol()),
            tls_version: Some(cf.tls_version()),
            tls_cipher: Some(cf.tls_cipher()),
            tls_client_random: None,
            as_organization: Some(cf.as_organization()),
        }
    }
} 

[spigaz]

@PeterMHammond I don't know the specifics, but you should have the API that you can call available and wrap it, including callbacks that you will have to expose to be called.

You mentioned serialization, I remember that Kevin at some point did some work on that in the context of their RPC, and that it worked manually.

The issues where more related on how to automate that, as either from WIT or with a macro it was no easy task.

[PeterMHammond]

@spigaz
Do you have a good recommendation on wiring up to the new SQLite that is now embedded in Durable Objects but not exposed to workers-rs? Just looking for a point in the right direction if you have one.
Thanks in advance.

[spigaz]

@PeterMHammond I haven't gave it a look yet.

But I would use the js API as reference, while giving a look to the current DO's persistence and the D1's workers-rs api.

[Sushi-Mampfer]

Has there been any official progress towards workflows in rust or any third party crate?

[connyay]

#918 👀