最近のlitestreamと安DB界隈
趣味開発でマネージドデータベースに課金したくない勢に安DBソリューションとして好評だったlitestreamについての近況をまとめてみました。安DBという謎の用語は「運用コストが安いデータベース」の意味で今作りました。 軽くおさらいするとlitestreamはSQLiteのレプリケーションを実現するミドルウェアで[1]、LiteFSはそれを分散環境に拡張してスケールをしようとしたもの[2]。 LiteFS Cloudはサ終した litestreamの技術をマネージドサービスにしようとたくらんだLiteFS Cloudは[3]、有料版が始まったかと思ったらいきなり提供終了した。 全然利用されなかったことが理由のようだ。確かにLiteFS自体が実験的な段階のソフトウェアな上にConsulサーバーと連携したり使いこなすのは難しい印象があった。 LiteFS は開発停止してる LiteFS自体は放
Hotwire/Honoなウェブアプリのアーキテクチャ
React Notes: MarkdownエディタのUIを作る 「React Notes」というReact Server Components(RSC)が発表された時期にReactチーム[1]やVercel[2]が公開していたブログ投稿デモサイトがあって、それをHotwireとHono/JSXで作ってみることでRSCなしに似たようなUXが作れるっていうのを示せるのではと思って、今クローンを作ってみています 現在はテキストエリアにMarkdownを入力するとプレビューをしてくれて、保存→更新の画面遷移がひととうりできるという部分のUIだけ先に試しに書いてみて以下にデプロイしました ソースコードがここにあります SSRな部分をHono/JSXのテンプレート処理系に寄せて クライアントサーバー通信と画面更新のコードはHotwire/Turboで簡略化 イベントハンドラな部分はHotwire/St
LLRTでHonoを動かす
LLRT (Low Latency Runtime)はAWS Labsの人たちによって公開されたOSSで、 「v8やJSCよりミニマムなJavaScriptエンジン付けてLambdaにデプロイしたらめっちゃ速くなるんじゃない？」というようなコンセプトを持つ新しいJavaScriptコードのランタイムです QuickJS[1]というES2023準拠のJavaScriptエンジンとそのRustバインディングのrquickjsを使って全体的に構築されています(LLRTはES2020と明記されていますが) ECMAScript(ES)にはないNode.jsの標準API群が一部Rustを使って書かれています JavaScriptから呼び出せるモジュールを「LLRTからロードできるネイティブなESMモジュールを追加する」で示したとうり自作できるので、Web Standard APIs互換なウェブフレー
なんでbun installは速いのか？
⚡️ 25x faster — Switch from npm install to bun install in any Node.js project to make your installations up to 25x faster. https://bun.sh/docs/cli/install という記述を見かけて直感的に、そうはならんやろと思ったものの実際にベンチマークをしているのでどういうことなのかを気になって調べた。 A global install cache. bun installを実行すると ~/.bun/install/cache/ 以下にnpmレジストリからダウンロードされたファイルの実体が展開されキャッシュされる(--cache-dirでパスを変更できる)。 キャッシュにはパッケージのバージョンごとのディレクトリとlatestのシンボリックリンクがある。こ
LiteFS入門
LiteFSとは LiteFSはLitestreamの可用性に関する課題を解決するために同作者によって新しく作られたソフトウェア。 Live Read Replication の実験的な機能ではノード間のHTTP通信でリードレプレカを同期してプライマリで書き込んだデータをrestoreを通さずにレプリカから参照することができるようになる予定だった。 この時書き込みクエリをプライマリに振り分けるのはアプリケーションの責務になる。例： ただそもそも複数台でLitestreamを利用する用途の為にノード間のLive Replicationを実装したとしても、デプロイやフェイルオーバーでノードの入れ替わりが発生する時に、無停止でプライマリを別のノードに切り替えることも考慮したりと、当初のLitestreamのスコープになかった新しい問題も出てくる。 なので「サーバー内のsqlite3ファイルをS3
Cloudflare PagesにNext.jsをデプロイするとSSRが動作するようになったのでどうやって実現されたのかを調べた
これまでの問題 Next.jsのEdge RuntimeはAPI RoutesやMiddlewaresのような単純なリクエスト/レスポンス変換を行う用途で提供されていてReact Componentをレンダリングする(SSR)にはNode.jsランタイム(主にNodeのStreams API)が必要だった[1]。 その上でCloudflare Workersの実行環境でSSRを実現するにはFastly Compute@EdgeのコンポーネントのようにNode.js APIの互換性問題を解決しプラットフォームに適合したグルーコードを生成することが要求された(fastly/next-compute-jsの内部アーキテクチャを調べるを参照)。 なのでCloudflare WorkersにAPI単体をデプロイ+Cloudflare Pagesにエクスポート済みの静的サイトをデプロイしてSPAで動か
RailsアプリケーションをVercelにデプロイしてISRする
「Nuxt3でのISR対応について調べる」や「Serverless FunctionsのCustom Runtimeを構築する」を経て、Vercelだいたい分かった状態になったため更に発展させてRailsでISRを動かす実験をしてみた。 条件 VercelのServerless Functionのruby27ランタイム(AWS Lambdaと同等)上で動かす a. Custom Runtimeで全部やるのはたいへんそうなので考えない Build Output API (v3) を使ってOn-Demand Incremental Static Regenerationする a. JavaScriptフレームワーク以外でもできるんじゃない？ という部分を検証したい せっかくRailsアプリケーションなのでViewやARも使ってMVCしたい データベースはPlanetScaleのMySQL互換サ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
