notion API で取得できる画像が 3600s で expire される(ので対応した)
Notion にアップロードした画像が含まれる block を API で取ってくると、画像は
といった感じで、 X-Amz-Date 付きの AWS の URL が降ってくる。
画像ファイルとか、他の API のエンドポイントを返したりせずに、保存してある S3 の url を返すのね。 期限付きにしているのも理解できるし、妥当な実装だと思う。
で、このサイトでベースにしている、notion-blog-nextjs は、この画像 URL をそのまま img の src に使ってしまっているので、よろしくない。
アクセスから 1 時間は画像が表示されるけど、それ以降アクセスすると画像がリンク切れ状態になり、その後 1 時間はまた復活する。といった感じになる。 アクセス数の少ないサイトでは致命的なので、ブログには不向きだと思う。
※ ちなみに、非公式 API のほうは Notion で署名付き URL だけど expire がない URL が降ってきていたので問題になっていなかった。
対応
素直に、元々の API の想定であろう方式にしたがって、API を叩いたらローカルにファイルを保存することにする。 とりあえず、動くだろうということでやっつけ仕事。
いらないファイルを消す、というのは未対応。やらなくて良いかなという判断。 万が一公開してはいけない画像を上げてしまったら手動対応しよう。
とはいっても問題もある
Note: Only assets that are in the public directory at build time will be served by Next.js. Files added at runtime won't be available. We recommend using a third party service like AWS S3 for persistent file storage.
https://nextjs.org/docs/basic-features/static-file-serving
にこの様に書いてある通り、public フォルダに配置できるのはデプロイ時だけで、その後 SSR の処理なんかで public にファイルを配置しても参照できない。 S3 とか使えって書いてあって、話が一周した感がある。
個人ブログだし、定期的に自動デプロイするようにしようかしら。 あるいは、書いたタイミングでデプロイするでも良いか。
ファイルサイズの軽減とか
あとは、処理の負荷が問題ないのなら、このタイミングで画像ファイルの軽量化する処理を挟んでも良いかもしれない。
どうも Notion にアップロードした段階で画像ファイルには一度変換の処理が挟まるようで、元の画像とは一致しなかったので、軽い画像を上げたつもりがまるまる太って返ってきた、というケースもあった。
なので、モバイル向けとか考えると、ここで何かしたほうが良いかもしれない。が、とりあえず様子見。
← Go home