先日、Fresh 2 のミドルウェアを作る方法について確認した。
ExpressやHonoに似たことで移植もしやすいことを見込んでいた。
なので移植する形で、実装しプルリクを出した。
結果、CORSミドルウェアとCSRFミドルウェアをFresh本体のリポジトリに入れ、CORSミドルウェアはマージとなった。
今回は、Fresh 2 の拡張として、プラグイン的なもの作ってみる。
Fresh 2 では、Fresh1のようなプラグイン機能は移植されていない。
しかし、Fresh2 のミドルウェアなら、ある機能のために複数の拡張をまとめて行うプラグイン的なものを、実装できるだろうことを見込んだ。
実際に試してみる。
Octo8080X/fresh2-password-auth-sampleにもアップしたので、全体を見たい場合はそちらを参照してほしい。
Fresh 2 についていつ出るんだろう。という話がよく聞くようになったこのタイミング。
公式がメッセージを出した。
公開について、2025年第3四半期後半（おそらく9月）というアナウンスがあった。
今回は、Fresh 2 alpha版を使って新しいAPI向けミドルウェアを作ってみる。
最近、サービス間の整合性とトランザクションそしてその中で一連の見せ方について、Sagaパターンに一定の理解を持つことができたので、メモを残しておく。
何をまた仰々しくと読む向きもあるだろうが、一定の結論を自分の中で持てるというのはそれ自体に価値がある。
最終的に Denoの提供するインフラ(ランタイムの機能)を利用し、Sagaパターンを下敷きにしたマイクロサービスが裏に控えるWebアプリを実装した。
先日読んだ「システム開発・刷新のためのデータモデル大全 著：渡部幸三」を読んでいました。
その中で、feature optionsという考え方が紹介されていました。
ある対象の属性群を別のテーブルで持つという考え方のものとなり、似たようなものを考えこそすれ、十分検討されたものだと感じました。
この考え方を踏まえ Active Record で試すとどうなるか確認します。
Tauri 2.0 が出てから久しい。
やろうやろうと引き延ばしてきたがやってみる。
Deno 2.1.8 が、2025年1月末にリリースされた。
このリリースの中に、feat(unstable): support https otlp endpoints という PR が含まれている。
そして 2月19日に公開された Deno 2.2 の公開で改めてリリースノートでも掲載された。
Deno 2.1.0 くらいからOTELがreleasesに載るようになっていた、
初期では、[OpenTelemetry Collector] といったデータを受信・処理・送出するサーバー/サービスを要していた。
先のプルリクで、https エンドポイントに対応した。
httpsエンドポイントに対応したことで、経験した範囲ではNew Relic に対して、データを送出できるようになったはずである。
今回は、それを試し共有する。
年初の記事として、メンテが滞っているモジュールのメンテをするというのがあった。
記事では1モジュールだけ挙げたが、そういったモジュールを2つ持っていた。
そのうち1つをメンテし、約4年ぶりでアップデートしてJSRで公開したので記録がてら書いておく。
2024年が開け、2025年になった。
このブログも、約3カ月振りの更新。
リハビリがてら、2024年を振り返り、2025年についてを書いてみる。
2024年8月、Deno Deploy が Web Cache API をベータサポートしました。
Introducing Web Cache API support on Deno Deploy
これまで、「cliでは使える」という状況でした。
Deno Deploy でも使えるようになります。
確認がてら、micro CMS との連携を試みてみます。