Zenn
🔑

[HonoX] メールやSlackでパスワードとか書きたくないときに

2024/03/31に公開
TypeScript
Cloudflare
JSX
Hono
HonoX
idea

パスワードや個人情報などをSlackで送るときには、DMが使われることが多いと思います。アクセスする人を最低限にする、という考え方ですね。

現実的な運用として全く問題はないのですが、「利用したら消しますね！」が面倒だったり、消さなかったり、そもそもSlackで繋がっていない社外の人に送る必要があるときなどはメールを使ったりしていて、どこかに残り続けることが不安でした。

見れる回数と時間を制限できてURLで共有できるサイト

kierubin.com

を作りました。コンセプトは見れる回数と時間を制限する。今はそれだけです。

ちなみにSlack等のチャットツールのDMは、ログインできなければ見れないので安全だと思います。
メールより本当に安全なの？と言われたら、SSLだし消えるので…くらいしか言えることはありませんが、
「できれば回数と時間を制限したいシーン」でお役に立ちたい気持ちです。

今後

特定のメールアドレスに送り、そのアドレスを保有していることを確認したら中身を開ける、
特定のアカウントに送り、アカウントログインにより本人を認証する、
などもやりたいのですが、とりあえずURLだけで送るだけの実装に。

準備はしているので、そのうち実装されます。Slack等のチャットツールとのシナジーも生みたいところです。

利便性と安全性（と安心）を叶える、色々なアイデアを募集中です。

HonoX

本題です。今年の2月に公開されたHonoXをCloudflare Pagesにデプロイする形で用いました。
データベースにはD1、データ暗号化用の鍵はCloudflare Secrets Storeを用いています。

昔(?)のPHPやRailsのようなテンプレートエンジンをサーバーサイドで使う開発体験は、開発者にとって認知負荷や実装量が少なく、魅了的だと感じていました。

一方で、ReactやVue,AngularなどSPA(だけではないですが)の台頭によって培われてきたインタラクティブなサイトを構築するための、あらゆる便利なOSS/技術資産を利用できることもまた、大きな魅力です。これら抜きにエンタープライズレベルやSaaSの構築は難しいのが現状でしょう。

昨今のRemixなどに代表されるトレンドはこの双方のメリットを得ようとする動きだと思っていて、HonoXはこのトレンドの中で重要なVite, JSX, islandアーキテクチャなどの資産を上手にHonoに組み合わせた、非常にわかり良い技術だと思います。これはHonoの話ですが、Web標準重視というのもトレンディですね。

今回は僭越ながら、HonoXについて特に良かったところをご紹介させていただきます。

特に良かったところ

Islandsアーキテクチャがわかりやすい

以前DenoのフレームワークであるFreshも少し触ったこともあり、ノンストレスで触れました。
Next.jsのApp Routerにおける 'use client'; も明示的にマークするアプローチで悪くないと思っていましたが、
パスが islands/ 以下かどうかでislandsなコンポーネントかを判別できるのは、認知負荷が非常に低いです。

最近のリリースに含まれたPRで routes 直下のComponent以外からもislandsが読み込めるなど、改善が進んでいます。

柔軟なResponseができる

例えばPOSTリクエストを受けるハンドラの実装がこうでもいいし、

export const POST = createRoute((c) => {
  return c.render(<h1>Post request executed!</h1>)
})

こうでもいい。

export const POST = createRoute((c) => {
  return c.redirect('after-post');
})

当然JSONを返すことなどもできます。

こちらにも記載がある通り、

Responseオブジェクトを返せばそれがそのままレンダリングさせるということです。

ということなので、サーバーサイドにて少ない記述量で振る舞いをここまで変更できるのは、新鮮な体験です。
「ここに置けばapiね」というapi routeアプローチとはまた違う感覚で、やりたいことを簡潔に実装させてくれるポテンシャルを感じさせてくれます。（アバウト）

今回は hono/jsx を用いて実装をしましたが、RendererをカスタムすればReactをレンダーすることもできる（らしい）。
hono/jsx の上では既存のReactのライブラリ等は依存関係上利用が難しいはずですが、
Reactをレンダーすれば、例えば react-hook-form 等も動作するのだろうか。要検証です。

Honoの柔軟なmiddleware機構とハンドラを駆使すれば、
要求の増加に応じてレゴみたくカスタマイズし、記述量は抑えつつ、要求に見合うフレームワークとすることができる。そんな感じを受けました。

そのうちFatなアプリケーションを作るために、HonoやHonoXをラップしたライブラリもまた出てきそう。

Vite

Viteのconfigをラップせず提供しているので、基本的にViteを使える方は困ることが非常に少ないはずです。（僕は詳しくないのでトライ＆エラーでしたが😇）

Cloudflare Pagesで動かすにあたっても、 @hono/vite-cloudflare-pages を使うことでスムースにビルドをしてくれました。

ちなみに vite.config.ts は大体こんな感じです。

import pages from "@hono/vite-cloudflare-pages";
import honox from "honox/vite";

export default defineConfig(async ({ mode, command }) => {
  if (mode === "client") {
    return {
      plugins: [client()],
    };
  }

  // ref: https://github.com/honojs/honox/issues/109
  if (command === "build") {
    return {
      plugins: [honox(), pages()],
    };
  }

  // ref: https://github.com/honojs/honox/issues/39
  const { env, dispose } = await getPlatformProxy();
  return {
    plugins: [
      honox({ devServer: { env, plugins: [{ onServerClose: dispose }] } }),
      pages(),
    ],
    server: {
      port: 5173,
    },
  };
});

次も使う

HonoXは個人プロジェクトでは十分実用に耐えるフルスタックフレームワークでした。
セットアップが早く、記述も少ない。過度なバリデーションや抽象化が不要な初期のプロジェクトにおいては、スターターキットをそのまま使えるでしょう。

さすが、Cloudflareとの相性もよく、無料枠の広いCloudflareプロダクト群もまた個人プロジェクトにシナジーがあります。

HonoXのバージョンは今日時点で0.1.9ですが、Viteは言わずもがなの安定性、Honoも今日時点で4.1.3です。
HonoとViteを組み合わせることに主眼が置かれている（と思っている）HonoX自体のバージョンは、実はそこまでクリティカルな問題を引き起こさないという考えのもと、
スタートアップ/ベンチャーの初期技術としての採用も、非常に有力なのではないかと思います。

僕は好きなのでそういうのは関係なくまた使います。（え）

Yusuke Wadaさんの今後の動向にも注目です。

Discussion