feat(js/client): added defineRemoteAction remote action client

[pavelgj]

import { defineRemoteAction } from 'genkit/beta/client';

const myFlow = defineRemoteAction({
  url: 'http://.../myFlow',
  inputSchema: z.object({ foo: z.string() }),
  outputSchema: z.string(),
  streamSchema: z.string(),
});

const { stream } = myFlow.stream(
  { foo: 'bar' },
  { headers: { authentication: getAuthToken() } }
);

for await (const chunk of stream) {
  console.log(chunk);
}

Checklist (if applicable):

• PR title is following https://www.conventionalcommits.org/en/v1.0.0/
• Tested (manually, unit tested, etc.)
• Docs updated (updated docs or a docs bug required)

[mbleigh]

Ugh, not sure what to do about the generics here. We're not actually doing validation here so in some ways I wonder about omitting the schemas for now and having the generics just be the realized types. You shouldn't have to import the zod schema and all of zod just to have the correct types on your remote action.

[pavelgj]

I'm super torn on this... my thinking was that if you share zod schema between the client and server, you can reused them here... but not sure how nice it is ergonomically... ideally you should be able to just take the flow (or action) reference and infer all the typing from it...

remoteAction({
  action: myFlow,
  url: 'https://...'
});

[mbleigh]

Yeah but right now that's not very feasible because trying to import myFlow into a browser environment will blow up the world. Although maybe with a pure type import...

import type { someFlow } from "./flows/someFlow";

remoteAction<typeof someFlow>();

[pavelgj]

@inlined managed to make this work in https://www.npmjs.com/package/@genkit-ai/next

[mbleigh]

should it just be remoteAction since there's no registry we're defining it into? but on the other hand define feels more consistent with the server side sdk..

[mbleigh]

We should consider exporting z from this file as well - import {z} from "genkit" will blow up Next.js if you do it from a file that runs in the browser