20251019

Microsoft Access

フォーム

Accessで管理するデータに対して、フォーム形式のGUIを通じてアクセスできるオブジェクト。

主に以下の用途で使用される。

  • データの入力・編集
  • データの検索・閲覧

フォームはユーザーが直接操作する画面となるため、操作性(UI/UX)やデータの安全性を意識した設定が必要。

データの安全性のための設定としては以下のようなものがある。

  • 削除前に確認ダイアログを出す
  • 自動保存ではなく「更新ボタン」を押して確定する方式にする
  • VBAを使用して入力値の妥当性チェック(必須項目・型チェックなど)を行う
  • 編集が不要なコントロールは「編集不可」に設定する
  • 「閉じる」ボタンで保存確認を行う(意図しない保存を防ぐ)

Accessではデフォルトが自動保存される仕様となっており、フォームを閉じたり移動したタイミングで保存処理が走る。操作感については感じ方がそれぞれだが、重要なデータについてはボタン押下による保存のほうが安心できる、気がする。

Next.js

キャッシュについてのメモ

Cache-Control

ブラウザのキャッシュとCDNのキャッシュ両方に影響する。

Cdn-Cache-Control

CDNのキャッシュ(Vercelのエッジキャッシュ含む)に影響する。

Cache-Controlの設定より優先される。

Vercel-CDN-Cache-Control

Vercelのエッジキャッシュに影響する。

Cdn-Cache-Controlより優先される。

ブラウザには送信されない。

ブラウザのキャッシュは配信側の手が届かないため、「更新したのに反映されていない」ということが起こりがち。

CDNのキャッシュであれば配信側から任意のタイミングで削除ができる。

そのためブラウザのキャッシュは極力使わず、CDNのキャッシュで最適化するのが良い。

Cache-Control ヘッダーはブラウザにも適用されてしまうため、キャッシュの有効期限等の設定は Cdn-Cache-Control で行う。

CDNで何でもかんでもキャッシュしてしまうと不具合が起こりやすい。特に、同じURLで「ログインしていない時」と「ログインしている時」で表示が違うページは要注意。さらにログインしている時に各ユーザーで表示が異なる場合はそもそもキャッシュしない方がいい。

Vary ヘッダーを使うと同じURLでも異なるキャッシュを保持できる(「ログインしていない時」と「ログインしている時」など)。 Vary ヘッダーにはリクストに含まれるヘッダー名を設定できる。指定したヘッダーの値ごとにキャッシュが保持される。

とはいえキャッシュの設定を少しでもミスると個人情報の漏えいにつながるため、よほど最適化したい場合でない限り、 Vary で複雑な設定をするよりも「このURLはキャッシュはしない」としてしまった方が楽。

RSCを使うことでURL単位でのキャッシュではなくコンポーネント単位でのキャッシュとなるため、キャッシュの複雑性を解決できるかもしれない。

ブログ

一旦キャッシュ関連を外してみた。

現在の状況としては以下の認識。

  • /blog/
    • 静的ルートのためビルド時に記事一覧をfetchしてデータキャッシュ + フルルートキャッシュ。
    • キャッシュはrevalidateを指定していないので更新されない。
  • /blog/***/
    • 動的ルートかつ generateStaticParams を指定していないためビルド時にはfetchしない。
    • リクエストのたびにfetchし、キャッシュはされない。
  • /blog/tags/***/
    • 動的ルートかつ generateStaticParams を指定していないためビルド時にはfetchしない。
    • リクエストのたびにfetchし、キャッシュはされない。

/blog/ が更新されないのは困るので以下の2つの方法が考えられる。

  • データキャッシュの revalidate を指定する
  • WebHook等を使用して任意のタイミングで revalidatePath または revalidateTag を実行する

この2つはポーリングとプッシュの違いに似ている(定期的に見に行くかデータ更新の都度通知をもらうか)。厳密にはリクエストがないと見に行かないし通知があっても破棄するだけで更新するわけではないので異なる。

もう一つの方法としてフルルートキャッシュの revalidate を指定する方法もあるが、多分データキャッシュが生きているので再利用されてしまう、はず。

データキャッシュの revalidate はフルルートキャッシュの revalidate にも使われるので、データキャッシュさえ更新されればページも更新される。

microCMSの場合WebHookを使った方法は2種類ある。

  • Vercelに通知を飛ばして再ビルド
  • Next.jsで受け取って自前で revalidatePath または revalidateTag

revalidate*** ではキャッシュを破棄するだけで再取得は行わない。一方再ビルドの場合はキャッシュは全て破棄されて再取得も行う。

コンテンツ更新のたびに再ビルドするのは少し冗長な気がする。