TypeScript SDK Syntax

[steebchen]

Hatchet needs a TypeScript SDK.

My syntax proposal:

Pushing events

client.event.push(
  "user:create",
  {
    id: "123",
    data: { username: "johndoe" },
  },
)

Worker

interface UserCreateInput {
  id: string
  data: { username: string }
}

type NextStep = string

const worker = new Worker({ client }) // any suggestions/alternatives?
worker.setup({ // .add / .setup / ...
  id: "on-create-do-stuff",
  desc: "Actions after user signs up",
  on: { // use either cron or event, can't use both
    cron: "*/5 * * * *",
    event: "user:create",
  },
  steps: [{
    name: "step 1",
    run: async (ctx: HatchetContext, input: UserCreateInput): Promise<NextStep> => {
      return `Hi, ${input.username}!`
    },
  }, {
    name: "step 2",
    run: async (ctx: HatchetContext, input: NextStep): Promise<NextStep> => {
      // do stuff
      return input
    },
  }],
})

[grutt]

Hi @steebchen this looks like a good first pass to me. I'll add some additional interfaces to align with this general spec.

Curious, have you put thought into the invocation of the step function? @abelanger5 and I were discussing and it seems like we might need to wrap the worker in something like a nextjs API route to support serverless/vercel deployments. I think this will be a common usecase for this sdk.

Also, I'm not sure how we plan to bundle these SDKs, but I think we'll want a typescript SDK and then a separate nextjs SDK that adds the route and depends on the typescript SDK. We'll likely need additional TS frameworks in the future. Make sense?

[abelanger5]

A couple of things to watch out for, for this function definition:

async (ctx: HatchetContext, input: UserCreateInput): Promise<NextStep> => {
  return `Hi, ${input.username}!`
}

Doesn't quite match the Go or Python SDK. ctx: HatchetContext should be able to access the input event via ctx.WorkflowInput(), and NextStep being a string value might not work with the current engine (which was written to expect JSON output types only - it could still work, just haven't tested it).

Dynamically deserializing the input and parent steps to strongly typed function arguments is a super nice feature, but adds considerable complexity to all of the SDKs, so perhaps we just keep using the HatchetContext mechanism with type-casting for now?

Also, will we require that the functions are async and return a Promise<T>?

Also, I'm not sure how we plan to bundle these SDKs, but I think we'll want a typescript SDK and then a separate nextjs SDK that adds the route and depends on the typescript SDK. We'll likely need additional TS frameworks in the future. Make sense?

@grutt this makes sense to me.

[steebchen]

Yeah indeed this uses the old Go SDK syntax.

Is it really required to have a nextjs SDK? Couldn't it be more like a serverless SDK? Although an actual NextJS SDK might be also useful, but it could be still published and depend on the serverless SDK.

[grutt]

Thanks @abelanger5 I noticed that but wasn't sure if it accepted either string or object.

Wrt strong typing, the big issue I see is that types might not live in the same service. For example, the typescript client might dispatch an event that is consumed by a Python service. Typecasting sounds like a solid first pass for this. As I get into it I'll poke at some other patterns