[Proposal] RPC

I’ll introduce an ultra cool feature. It will improve our developer experience. This issue is a continuation of #602.

“tRPC” is helpful for sharing the types between the server and the client. This means it makes the types an API specification. There is a request to make tRPC adapter #582 , I think it’s good to make the adapter as 3rd party middleware.

So, tPRC is great, but we can do it in a better way with Hono because we can make it “integrated”.

What we want to do are below:

• Share the request format inferred from the validation schema.
• Share the response format inferred from JSON objects that is returned in a handler.
• Implement “client” not only on the server-side.

Then, I have created those prototypes. They are not fully implemented, but they work. See the screencast:

Server-side code:

const api = new Hono()

const getRoute = api
  .get('/hello', (c) => {
    return c.jsonT({
      messages: 'hello',
    })
  })
  .build()

const postRoute = api
  .post(
    '/posts',
    validator((v) => ({
      id: v.json('id'),
      title: v.json('title'),
    })),
    (c) => {
      const post = c.req.valid()
      return c.jsonT({ title: post.title })
    }
  )
  .build()

export type AppType = typeof postRoute & typeof getRoute

Client-side code:

import type { AppType } from './server'

const client = new Client<AppType>('http://127.0.0.1:8787/api')

const res = await client.get('/hello')

console.log(res.messages)

const res2 = await client.json('/posts', {
  id: '123',
  title: 'Hello!'
})

console.log(res2.title)

The client-side needs to be considered, but this is a good idea for the server-side API. And, if developers want to use 3rd party validator like a “Zod”, they may use it.

Notes, we need to brush up on our data structures to handle types with Generics.

Isn’t it cool? I may create the PR later.

[cleaton]

@yusukebe Thank you for your response! Have you thought about how it would handle multipart/form-data?

You are thinking about file upload? I think each client method is a specific spec. For example client.json() is a POST request with content-type application/json. Similarly there could be a client.upload() that uses multi-part though I’m not sure that’s need for a first release to keep things simple.

[cleaton]

Looks great! I like the API.

Some thoughts I’ve had wile working with my “type-knit” project that might be relevant here as well:

1. Cloudflare Durable Objects & services are exposed as stubs with a “fetch” method. This stub could have a client wrapper (that does not need url) to be used on workers (micro service RPC)
2. It might be best if the client returns a composable type instead of directly returning the api type. Ex ‘Result< T >’ . This way response object could be passed from DO to worker to web client without serializing in worker (only deserialize on result unwrap). Ex: ‘’’worker

const postRoute = api .post( ‘/posts’, validator((v) => ({ id: v.json(‘id’), title: v.json(‘title’), })), © => { const post = c.req.valid() return DoClient(dostub).json(“/increment”, {title: post.title}) } ) .build() ‘’’