❓ Interop with zod function schema

[lorefnon]

Thanks for creating this library. I was exploring similar solutions for a new project I am working on and this looks very close to what I wanted.

I am curious if it makes sense for this library to interop with zod function schemas.

Basically I have a few services which are pure (in the sense they are not http aware). I'd like to expose them as http APIs (as well as graphql). I was wondering if you think it is a good idea to be able to take a function schema and effectively "lift-it" to an express middleware.

The intent is to keep the core services pure so that they can be invoked from non-http contexts (eg background jobs) as well.

[RobinTail]

Hello @lorefnon ,

Could you please provide some example on how exactly Zod function schema could be useful for this case?
I'm struggling to understand it so far.

Thank you

[lorefnon]

@RobinTail Thanks for getting back. Basically I was thinking of an API like:

In schema.ts (shared between client and server):

// Normal zod types
const PostInput = z.object({
    title: z.string(),
    body: z.string().optional()
})

const Post = PostInput.and(z.object({
    id: z.string()
}))

export const createPost = z.function()
    .args(
        // Uses extensions to zod api for http handlers
        z.string().asPathParam('sectionId'),
        PostInput.asBody()
    )
    .returns(z.promise(Post))

export const createPostPattern = '/sections/:sectionId/post'

In service.ts (server side implementation, http independent)

export const createPostImpl = createPost.implement((sectionId, postInput) => {
    const id = savePost(/* ... */)
    return { id, ...postInput }
})

In server.ts (server side implementation, express integration):

app.use(createPostPattern, createPostImpl.asMiddleware())

In client.ts (http client)

export const createPostImpl = createPost.asFetchClient({ pattern: createPostPattern })

Key points:

1. No codegen needed for client
2. The transport is abstracted - the contract (for both service implementation as well as client) is defined by the function schema. We could potentially swap the transport to use websocket with change only in server.ts and client.ts - the consumer of API and service implementation don't have to change at all.