How to code large applications with large handlers in multiple files.

[movahhedi]

I have a mega-scale application with over 600 tables in it's DB, with a peak of about 200 requests/s. It needs a full re-codeing.
I'm considering Hono for the new version. Since each of these 600 complex entities at least has CRUD operations, there will be more than 600x4~=2500 routes.

1. Can Hono's RPC (with zValidator), handle the types of the requests & responses of all these >2500 routes? Will there be a performance issue with TypeScript?
2. (The main question) Since the handlers/middleware handling these routes are large, I want to handle each of the C,R,U,D each in a separate file. How should I code this? Should I create a Hono instance for each like this? That would be >2500 Hono instances. Won't that be a performance issue? Even not for the developers using RPC? Are you sure?
3. How should I create the tree of routes (AppType) for these 600 entities in the index file imported by the client-side and used with hc<AppType>?

Your answer would be much appreciated @yusukebe.

[yusukebe]

Hi @movahhedi

I'll answer them:

1 . Can Hono's RPC (with zValidator), handle the types of the requests & responses of all these >2500 routes? Will there be a performance issue with TypeScript?

Unfortunately, it will be impossible. You are right; it will be the issue with TypeScript. To benchmark it, you can create an app with many routes with the following script:

import { writeFile } from 'fs'

const generateRoutes = (count: number) => {
  const imports = `
import { Hono } from 'hono';
import { z } from 'zod';
import { zValidator } from '@hono/zod-validator';
`

  const schema = `
const schema = z.object({
  q: z.string()
})\n
`

  let routes = imports + schema + 'export const app = new Hono()\n'
  for (let i = 1; i <= count; i++) {
    routes += `  .get('/route${i}/:id', zValidator('query', schema), (c) => {
    return c.json({
      query: c.req.valid('query'),
      id: c.req.param('id'),
      ok: true
    })
  })\n`
  }
  return routes
}

const count = 300
const routes = generateRoutes(count)

writeFile('app.ts', routes, (err) => {
  if (err) throw err
  console.log(`${count} routes have been written to app.ts`)
})

The IDE can't handle over 300 routes on my machine. Below is the error message when it has many handler limits of the number:

So, you need to separate the routes if you want to use the RPC feature.

2 . (The main question) Since the handlers/middleware handling these routes are large, I want to handle each of the C,R,U,D each in a separate file. How should I code this? Should I create a Hono instance for each like this? That would be >2500 Hono instances. Won't that be a performance issue? Even not for the developers using RPC? Are you sure?

Yes. It will be good to use this method. Creating an instance of Hono is only performed at application initialization time, so once up and running, there is no cost to do new.

Please see the following comment I wrote: https://github.com/orgs/honojs/discussions/2066#discussioncomment-8239397

But regardless of which framework you use, I believe 2500 routes are too large. In my opinion, it is better to separate the applications. You can refer to this comment: https://github.com/orgs/honojs/discussions/2066#discussioncomment-8239698

3 . How should I create the tree of routes (AppType) for these 600 entities in the index file imported by the client-side and used with hc<AppType>?

It is difficult to handle 600 routes in a client created by hc, so it is better to separate routes per app ( book or author in the following case).

// src/routes/book.ts
const book = new Hono()
  .get('/', (c) => c.json(0))
  .post('/', (c) => c.json(0))
  .put('/', (c) => c.json(0))
  .delete('/', (c) => c.json(0))

// src/main.ts
main.route('/book', book)

// client of a book
const bookClient = hc<typeof book>('/book')

// ...

// src/routes/author.ts
const author = new Hono()
  .get('/', (c) => c.json(0))
  .post('/', (c) => c.json(0))
  .put('/', (c) => c.json(0))
  .delete('/', (c) => c.json(0))

// src/main.ts
main.route('/author', author)

// client of an author
const authorClient = hc<typeof author>('/author')

[movahhedi]

Thanks for your response @yusukebe.

So, you need to separate the routes if you want to use the RPC feature.

So if I distribute these 2500 routes in like 25 hcs (100 routes per hc), there won't be a problem?

[yusukebe]

So if I distribute these 2500 routes in like 25 hcs (100 routes per hc), there won't be a problem?

Maybe yes. Trying it yourself is the best way, but I think it works fine. I tried the RPC with 100 routes on my machine and it can work.

[movahhedi]

I created a repo with the code you sent, and tweaked it to create multiple hc endpoints, For anyone interested: @movahhedi/hono-test.

[movahhedi]

With the code @movahhedi/hono-test, I created 15 Hono instances, each with 200 routes (15x200 = 3000 routes), without any hcs (just the server-side). But defining the routes itself caused significant slowness in TypeScript; when writing new a new line, the Intelisense takes 13 seconds to pop up, and running tsc on it takes 13s too.

Is it possible to create a version of Hono, remove some less-used features, make it lightweight for TypeScript that can handle large codebases (just like how you created hono/tiny, nut instead of being small in size, be performant with TypeScript)?

Even for the server-side itself (without hc), I think Hono is a great choice of a webserver, and I would like to find a way of using it for my applications from now on.

[tomByrer]

I the real issue here with the TypeScript interpreter/transpiler?
The official 'tsc' is known to be slow; other projects, like Bun & some other Rust-based transpilers claim to be faster. Note, currently there is no TS runtime, they all transpile to JS or JS bytecode.

You might have to program in only in JavaScript, isolate each database into its own application (even if you use a master template), or just use another language.

[telcy]

I am currently evaluating using hono rpc and ended up facing the same issue.

I tried using OpenAPI schemas as well:

import { writeFile } from "fs";

const generateRoutes = (count: number) => {
  const imports = `
import { OpenAPIHono, createRoute } from "@hono/zod-openapi";
import { hc } from "hono/client";
import { z } from "zod";
`;

  let routes = imports + "const api = new OpenAPIHono()\nconst app = api";
  for (let i = 1; i <= count; i++) {
    routes += `.openapi(createRoute({
  method: "get",
  path: "/hello${i}",
  request: {
    params: z.object({ test: z.string() }),
  },
  responses: {
    200: {
      content: {
        "application/json": {
          schema: z.object({ hello: z.literal("world") }),
        },
      },
      description: "Get hello!",
    },
    400: {
      content: {
        "application/json": {
          schema: z.object({ error: z.string() }),
        },
      },
      description: "Bad request!",
    },
  },
}), (c) => {
  const { test } = c.req.valid("param");
  return c.json(
    {
      hello: "world" as const,
    },
    200
  );
})\n`;
  }

  routes += `
const client = hc<typeof app>("http://localhost:3000");
const req = await client.hello1.$get({ param: { test: "123123" } });

if (req.status !== 200) {
  throw new Error("could not fetch data");
}

const res = await req.json();
// === "world"

console.log(res.hello);
  `;

  return routes;
};

const count = 300;
const routes = generateRoutes(count);

writeFile("app.ts", routes, (err) => {
  if (err) throw err;
  console.log(`${count} routes have been written to app.ts`);
});

[Meess]

I guess that's the price to pay when having the full api type inferred, typescript has never been fast for complex types and inferences.

You're also writing everything to one file, which makes it difficult for TypeScript to cache anything and having to typecheck the entire file on a change.

One thing that was already mentioned is splitting it up into multiple apps (see answer to question 3 )

If neither of these work conveniently you might want to look at a monorepo tool like NX to split it up into multiple smaller libraries, which is definitely justified if you have that many routes. Really curious what these usecases are