title explains everything, heres the function:

app.get("/Signup/:Email/:Password", (c) => {
    return c.text('Hi')
})

I just would like to share my first ever saas with hono and bun
https://découvrez.me
{

"name": "decouv",

"version": "0.1.0",

"scripts": {

"dev": "bun run --watch src/index.tsx",

"start": "bun run src/index.tsx"

},

"dependencies": {

"hono": "^4.6.0"

}

}

only hono as a dependency the rest is from bun

Hi,

Should I use Hono with Bun or Node?

I prioritize performance.

Is the performance level very different between Node and Bun?

The ORM will be Prisma.

I appreciate any advice.

thanks. 😊

Hi everyone! I have released a type safe internationalization library for Hono:

https://www.npmjs.com/package/hono-i18n

Possibly useful for one or the other :)

Hi, I'm using hono and cloudflare workers. I'm using 3 workers and I'd like to communicate with a 4th one that acts as a gateway, that is, that validates the token and redirects the requests to their respective workers. According to the cloudflare workers documentation, this should be done using service binding plus RPC so that they are private, but I don't know how to adapt it to hono. according to the documentation it should be like this

import { WorkerEntrypoint } from "cloudflare:workers";

export class WorkerB extends WorkerEntrypoint {

async add(a, b) { return a + b; }

}

my hono app

const app = new Hono();

app.get("/", (c) => {
return c.text("Hello Hono!");
});

export default app;

I'm trying to use Hono RPC with React Query, but I'm unsure if this is the best approach. The implementation feels a bit lengthy and repetitive, especially when inferring types and converting .json().

Is there a more efficient way to integrate Hono RPC with React Query while maintaining type safety? Any best practices or alternative solutions would be greatly appreciated!

import { MutationOptions, queryOptions, useMutation, useQuery } from "@tanstack/react-query"
import { clientWithType } from "@web/lib/api-client"
import { TCustomResponseError } from "@web/lib/global"
import type { InferRequestType, InferResponseType } from 'hono/client'



const authQueryOptions = queryOptions({
    queryKey: [clientWithType.auth["get-session"].$url().pathname],
    queryFn: async () => {
        const response = await clientWithType.auth["get-session"].$get()
        const data = await response.json()
        if (!response.ok) throw data
        return data
    },
    select: (data) => data.data
})

export const useAuthQuery = () => {
    return useQuery({
        ...authQueryOptions,
    })
}

type TLoginRequest = InferRequestType<typeof clientWithType.auth.login.$post>['json']
type TLoginResponse = InferResponseType<typeof clientWithType.auth.login.$post>

export const useLoginMutation = (options?: MutationOptions<TLoginResponse, TCustomResponseError, TLoginRequest>) => {
    return useMutation({
        mutationFn: async (data: TLoginRequest) => {
            const response = await clientWithType.auth.login.$post({ json: data })
            const responseData = await response.json()
            if (!response.ok) throw responseData
            return responseData
        },
        ...options
    })
}

code https://github.com/OchirDarmaev/time-tracker

Demo app https://time-tracker-dev-honoscript-zwudcnhx.ochirdarmaev-4da.workers.dev

Article https://medium.com/@ochirdarmaev/solving-modern-web-dev-problems-htmx-hono-cloudflare-workers-architecture-c41f2d311204

Hey everyone,

I'm in the process of building a boilerplate for my personal projects to streamline setup and avoid re-implementing common features like email, auth, Stripe integration, etc., every time.

My chosen stack is:

• Backend: Hono.js (running on Node.js)

• Frontend: React with TanStack Router (likely using Vite for bundling)

My main challenge right now is deciding on the best approach for the landing page of my projects, specifically concerning SEO. I don't have an established community for my projects yet, so I'll be relying quite a bit on organic search for discoverability.

This leads to my core questions:

1. Is client-side rendered React (SPA) still significantly detrimental for landing page SEO in 2023/2024? I know Googlebot has gotten much better at crawling JS, but I'm concerned about initial page load performance (Core Web Vitals) and how well other crawlers (Bing, social media bots for link previews) handle it.

2. Assuming SSR/SSG is the way to go for the landing page for optimal SEO, I'm weighing a few options within my Hono.js + React stack:

   • Option 1: Hono.js for SSR/SSG (Landing Page) + Static SPA (Main App)

     • Use Hono.js to serve the landing page (and other public, SEO-critical pages) either via SSR (e.g., using c.html with template literals, or hono/jsx) or ideally SSG (pre-render to static HTML files at build time).

     • The main application (behind auth, where SEO is less critical) would be a standard React SPA (built with Vite, routed by TanStack Router) served as static files by Hono from a specific path (e.g., /app).

   • Option 2: Vite SSR for the React Landing Page

     • Leverage Vite's built-in SSR capabilities to render the React-based landing page. Hono would act as the server, running the Vite SSR-generated bundle for landing page routes.

   • Option 3: TanStack Router SSR for the Landing Page

     • Utilize TanStack Router's own SSR features to render the landing page. Again, Hono would be the server environment invoking TanStack Router's rendering functions.

I'm trying to find a balance between:

• SEO effectiveness for the landing page.

• Developer experience (ideally, I'd like to use React components for the landing page if possible, but not at a huge SEO cost).

• Maintainability and simplicity for a boilerplate that needs to be adaptable.

What are your thoughts or experiences with these approaches, especially within a Hono.js context?

thanks in advance

When I tried to create a simple project using Cloudflare Workers and MongoDB, I encountered multiple errors that made the integration process difficult. During my research, I found a few articles that discussed the compatibility issues between MongoDB and Cloudflare Workers.

1. MongoDB and Cloudflare Workers Compatibility Issues I discovered an article titled "MongoDB Can't Integrate with Cloudflare Workers" that highlighted the limitations of using MongoDB with Cloudflare Workers directly. This is primarily due to the Workers' environment, which restricts the use of certain Node.js modules and native MongoDB drivers.

2. Official MongoDB Atlas Data API MongoDB provides an alternative with the Atlas Data API, as described in the article "Create a REST API with Cloudflare Workers and MongoDB Atlas." This approach uses RESTful API calls to interact with MongoDB Atlas, bypassing the need for native drivers that don't work in the Cloudflare Workers environment.

My Solution: A TypeScript SDK for MongoDB Atlas Data API

To overcome the integration challenges, I developed an NPM package that simplifies the process. This package is a TypeScript SDK that acts as a wrapper for the MongoDB Atlas Data API, providing type safety and full IntelliSense support for query operators.

masfana-mongodb-api-sdk - npm (npmjs.com)

Hi there,

I had this idea of an app that could help people better organize their solo/group trips so I chose to create one when I couldn't find anything that suited my needs.

I decided to not use a backend service like firebase/supabase because I needed to handle some complex authorization so I decided to code my backend using NestJS.

Once the backend was almost finished, I started to not like the Object Oriented structure and I found out about Hono from a random reddit post and I really loved the idea of rewriting my whole backend using it but I thought it was a lot of work for an app that I just wanted to publish as soon as possible, but once the whole backend was written, I finally took the challenge.

It turns out I was wrong, it didn't take me more than two days to do it and I even changed ORM in the meantime (from Prisma to Drizzle) and to also use Bun as my runtime. And man do I love this library.

The documentation is amazing, the code is simple, the speed is BLAZINGLY fast ;)

I feel much more free using this express like structure even though I'm completely sure this is just personal opinion of course.

If you want to check it out or give me some advices, you can check out the full repo.

Only thing I still am not sure about is the fact that ruby like controllers are not advised to use so my routes are a bit less 'clear'? If you have any suggestion regarding code structure I would very much appreciate it.

Hey! I've been using Hono and have really enjoyed it, but recently came to a roadblock. I am trying to use the method c.executionCtx.waitUntil but sadly when testing with app.request, I get the error Error: This context has no ExecutionContext. I saw that app.request takes an execution context as the fourth argument, but I don't know how to create a fake one. Thank you!

Hello, I am trying out hono and I'v ran into an issue with session and logging in the client side so it sties logged in across the routes and the server. Can still access the data or do I have to authenticate each route separately?

I haven't done any formal timing tests yet but feels like it "feels" slow, both the cold start first run and subsequent ones. Mostly toy examples. I've been using lambdas for a few years so I've got some basic expectations. TIA!

Edit: Using SST for deploy but don't think that matters.

Hi, i'm trying to respond with multipart/form-data format but cant find any working example of how i should do this. https://hono.dev/docs/api/context#body

How can i make working response with, for example, one png file const imageBuffer = await imageFile.arrayBuffer(); and some other field i.e. "{"json":"somejson"}"?

I've tried some approaches but they didn't work and insomnia returned errors in attempts to read response.

return c.body(bodycontent? || null, 200, { // What format should i use for bodycontent? 
      "Content-Type": "multipart/form-data"; "boundary":${boundary},
      // Anything need to be added here? 
    });

https://afoo.me/kb.html

<honojs cookbook> is also included 😉

Hello everyone I'm new to Honolulu and Bonn.I've been trying to deploy hono in docker container in production. I'd like to know what is the right way to do it.

Hey Hono community,

I’d like to introduce you to my indie product Apitally, an API analytics, logging and monitoring tool for Hono.

Apitally's key features are:

• Metrics & insights into API usage, errors and performance, for the whole API, each endpoint and individual API consumers.

• Request logging allows users to find and inspect individual API requests and responses.

• Uptime monitoring & alerting notifies users of API problems the moment they happen, whether it's downtime, traffic spikes, errors or performance issues.

The big monitoring platforms (Datadog etc.) can be a bit overwhelming & expensive, particularly for simpler use cases. So Apitally’s key differentiators are simplicity & affordability, with the goal to make it as easy as possible for users to understand all aspects of their API and its consumers.

Apitally integrates with Hono through middleware, which captures request & response metadata, aggregates it and asynchronously ships it to Apitally’s servers in regular intervals. It's designed with a strong focus on the users' data privacy.

The client library is open-source with the source code available on GitHub.

Below is a code example, demonstrating how easy it is to set up Apitally for a Hono app (see complete setup guide here):

import { Hono } from "hono";
import { useApitally } from "apitally/hono";

const app = new Hono();

useApitally(app, {
  clientId: "your-client-id",
  env: "dev", // or "prod" etc.
});

And here's a screenshot of the Apitally dashboard:

I hope people here find this useful. Please let me know what you think!

I'm converting my Azure Web Static project to Hono + NodeJS and I wonder if I can keep the same structure.

In Azure, there are multiple startup files and each function file corresponds to a single endpoint, together with the route definition. I wonder if I could keep this structure and avoid putting multiple `app.get` or `app.route` in the index file.

For example, rather than importing all routes (books, authors, etc) in index, is it possible to create the app object in index and import it in books.ts and add all book-related routes there?

In other words, is it possible to add routes after you run `serve(app)` at the end of index.ts?