New middleware structures, and how we manage

[yusukebe]

I want to renew middleware structures for v2.0.0. I'll tell you my plan roughly.

There are two types of middleware:

1. Built-in middleware

Basic. It does not depend on other libraries. Such as basic-auth, cors, etag, jsx, and so on. Included in hono packages. So, we can use hono/{name} syntax like this:

const { cors } from 'hono/cors'

2. Third-party middleware

Extended. It depends on other libraries. Such as graphql-server, mustache, or firebase-auth. These are not included in hono package but distributed by @honojs/{name} package. like this:

// Install
npm i graphql
npm i @honojs/graphql-server

// Code
const { graphqlServer } from '@honojs/graphql-server'

And, these middleware are managed in under honojs org on GitHub. Each middleware has its own repository. Such

https://github.com/honojs/graphql-server

honojs org in npm

Already, I've got honojs org in the npm repository.

https://www.npmjs.com/org/honojs

We can use @honojs/{name} namespace.

Privileges

We have to think about the privileges of managing third-party middleware.

Basically, I keep managing github.com/honojs/hono for hono package including built-in middleware.

And, the GitHub repository and npm package of third-party middleware is managed by the author of it. To do it I'll give privileges to access GitHub and npm repo to the author of the middleware.

For example. If @Code-Hex wants to make firebase-auth middleware, I will give the privileges to manage GitHub github.com/honojs/firebase-auth and npm @honojs/firebase-auth. The author is free to use the repository for development and release it to npm freely.

How to

For example:

1. Remove graphqh-server middleware from honojs/hono repository. And move it to honojs/graphql-server.
2. Publish as @honojs/graphql-server on the npm repository.
3. Make honojs/firebase-auth repository.
4. Add @Code-Hex to GitHub honojs org and add privileges to manage honojs/firebase-auth repository.
5. Make @honojs/firebase-auth
6. Add @Code-Hex to the npm repository honojs and add privileges to release and manage@honojs/firebase-auth.

---

It's just an idea. We have to consider it.

[yusukebe]

Or we can compose third-party middleware by monorepo pattern like the project @Code-Hex taught to me.

https://github.com/dotansimha/graphql-code-generator/tree/master/packages/plugins/typescript

In monorepo pattern, all third-party middlewares are in one repository. Such as github.com/honojs/middleware. And these will be placed under the packages directory such as packages/graphql-sever.

The nice thing about this pattern is that it allows for common test code and packages. Instead, middleware authors will not be free to configure the project.

[Code-Hex]

Thanks for a lot of writing down your thinking.

Indeed, it may be better to have separate repositories for each package if you give privileges rights to each package (This is my opinion).

Summary of Pros, Cons of management. I'd like to know if there's anything else you'd like to share.

Non-monorepo

Pros

• Ownership can be transferred in an easy way that is independent of @yusukebe -san.
• Issues and pull requests are easier to organize as they are held in their own repositories.
• Release flow is essentially independent of honojs framework.

Cons

• May be hard to keep up with honojs framework breaking changes.
• If the repository owner is not available, they need to think about how to maintain it.

Monorepo

Pros

• When honojs framework is updated (or happened breaking changes), it is easy to follow the content.
• Can always be reviewed by one of the maintainers involved in honojs org.

Cons

• Release flows may become more difficult.
• The maintainer needs to know everything.
  • However, CODEOWNERS can be used to assign reviewers on a directory basis.

[yusukebe]

Hi @Code-Hex ! Thank you for summarizing.

I think the monorepo pattern is good. It's easy to make settings of projects to be common. But, if we think about Deno, it will be difficult to use monorepo.

On Deno, the version is specified by the GitHub project's tag name. For example, if the latest tag is v0.1.0, Deno's modules' version will be v0.1.0. If all third-party middleware is in the monorepo, we can't make versions independent. We want to publish middleware A as v0.1.0 but the project tag may not be v0.1.0.

I don't think all modules need to be Deno modules, but this is important.

So, I'm planning to use no-monorepo pattern. In the non-monorepo pattern, it's difficult to follow the version up of Hono as you said and it's treble to set up projects for each middleware. However, I think it can't be helped. We can try and find improvements such as using Dependabot/Renovate to follow updates of Hono and making the example project for reference.

If you know of a better solution, please let me know.

[Code-Hex]

Thanks @yusukebe

I see. I don't have release strategy for deno.

This is agree me.

I don't think all modules need to be Deno modules, but this is important.

I'm fine non-monorepo pattern 😄

[yusukebe]

@Code-Hex Thank you!

I'm making the template project for third-party middleware.

https://github.com/honojs/middleware-template

It's just PoC status. We might use this template after releasing v2.0.0 to develop third-party middleware.

[Code-Hex]

@yusukebe Great work!

https://github.com/honojs/middleware-template

I understand. but I have one question. What do you think about the release flow for npm?

Currently, you considering releasing by using honojs org. I think we should support deployment via GitHub Actions. Because you can share npm token via secrets for an organization. I believe this is a safe way (maybe).

[yusukebe]

@Code-Hex Thank you!

What do you think about the release flow for npm?

I was just thinking about it!

I think we should support deployment via GitHub Actions.

I think so, it's a better solution. So, I'll try to set up GitHub Actions with middleware-template repository later.
I've had a quick look, and this GitHub Action looks good.

https://github.com/marketplace/actions/publish-to-npm

[metrue]

I think it's great to manage the third-party middleware in individual repo, which benefits,

• development
  it's flexible to try new techs.
• maintenance
  easer code review and simple CI/CD pipeline.

[yusukebe]

Going to #407