最近、LLMにWeb Backendを書かせて遊ぶ、Hanabiというサービスを作っています。その開発過程で、前に試したLLMをAPIとして振る舞わせるアプローチを再検討したので、記事としてまとめました。 一年ちょっと前、私はChatGPTをWebフレームワークにしようと試みました...が、残念ながら全く実用的ではありませんでした。しかし、あれから一年、LLMは目覚ましい進歩で進化を遂げました。価格は下がり、速度も上がり、記憶容量の増加やRAGの発展など、もはや別物レベルで進化しています。 いまならもうちょっと実用的なヤツが作れるんじゃねってことで、色々な手法を面白がった再検討したまとめです。 余談ですが、一年前はLLM=ChatGPTという状況でしたね...懐かしい。ちょうどvicuna13Bが出た頃ですかね? ↓去年の記事(できれば読んでほしい)↓ 出来たもの 全部プロンプトに入れちゃ
見よ、これがHonoのRPCだ
僕が開発しているWebフレームワークHonoは、同じJavaScriptのフレームワーク、Expressと比べられることが多いです。どちらもやれることはほぼ同じですが、HonoのアドバンテージはファーストクラスでTypeScriptをサポートしていることです。特に「RPC」機能は他のフレームワークにはなかった「TypeScriptの型でサーバーとクライアントの仕様を共有する」ことを可能にしています。今回はそのHonoのRPCについて紹介します。 どんなものか まず、どんなものかを箇条書きで共有します。 Web APIの仕様、特にインプット・アウトプットをサーバーとクライアント間で共有するためのもの OpenAPIやgRPCを使ってやりたかったことを叶えるかもしれない サーバーとクライアントをどちらもTypeScriptで書くことが大前提である 同種のものにtRPCがあるが、Honoの場合、
株式会社 CoeFont でフロントエンドエンジニアをしている uzimaru です。 Next.js の Middleware で Hono を使ってみたのでそれについて記事にまとめます。 モチベーション Next.js の Middleware はアプリケーションに1つだけしか設定出来ず、どの path で実行するかの設定も config を使って正規表現や Header, Cookie を指定して設定するかリクエストの pathname を見て処理を分岐する必要があります。 シンプルな実装のみなら良いのですが、path によってログインしているか確認したい、いくつかの処理を Middleware で適応したい、というように要件が複雑になると管理が大変になっていくと思います。 そこで、Hono のようなシンプルなフレームワークを Middleware で動かして実装をシンプルにしようと
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
LLMをWebフレームワークにしたら、未来が見えた #2024
Next.js の Middleware で Hono を使う