はじめに
こんにちは、こふです。
真面目な記事です。
一般的な予約投稿の実装
Web サーバーで毎回 Web ページを生成してユーザーにデータを返すことが一般的です。WordPress が一般的な実装をしている気がします。ソースコードは読んでいません、予想です。
つまり、投稿日時を「2222/02/22」と設定すると、その記事の一覧・詳細を SQL クエリなどで抽出する時に WHERE 条件などで現在のタイムゾーンと比較して、それより小さいなら、その記事を返すことで予約投稿のようなことが可能になります。
実装の観点としては、投稿日時のデータのみデータベースで扱っておけば、公開・非公開のフラグを持たないことも可能なので便利。
ただ、記事内容にミスや、問題を引き起こす何かが存在した場合、非公開にするために投稿日時を変更する必要が出てきてしまうため、適切とは言えない場合もりますね。
特にニュースサイト・メディアなど。その場合は、公開非公開のフラグと投稿日時で良いでしょう。
当然、時間になったら Twitter で宣伝する、というなら、受動的な投稿ではなく、肯定的な投稿（投稿をすることにトリガーする何か）を実装する必要はありますね。
静的なサイトで実装するには？
静的なサイトとは、どこかの Web サーバで先に生成した情報（Web ページ）をユーザに返して閲覧するサイトを指します。
動的なサーバ・クライアントでの描画がないサイトです。
具体的なライブラリの名前を出すと、Hugo、Nextjs の静的ビルドなどが当てはまります。
その上で以下の 2 つの方法を思いつきました。
- 毎日決まった時刻に自動でビルドする
GitHub Actionsで新規記事のブランチを特定の時刻に自動でマージする
順に解説します。
方法 1：毎日決まった時刻に自動でビルドする
これが一番有効かつ実用的だと判断し、本サイトでも実装予定です。
投稿日時を Frontmatter に設定しておき、記事一覧の絞り込みとして、ビルド時の時刻との比較をします。特定ページでも同様に比較し、公開・非公開を決めます。
ただ、Web サーバーがどの国にあるか不明な場合が多いのですが、時刻の扱いを適切にしなくてはなりません。テストコードをきちんと書いても挙動が異なる可能性があるため、検証が必要そうです。
UTC 時刻を確実に取得し、日本との時差を加えてあげるのが無難だと思います。
こうしてあげると、5 つの記事を書き溜めていたとしても、適切な日時を設定してあげることで更新の面倒を見る必要がなくなります。
この場合は、公開・非公開のフラグも持てるのですが、CDN のキャッシュ次第では非公開にしてもすぐに非公開にならず困る点もありそうです。
また、時間の指定もできますが、するとなると毎時ビルドしますし、使っている静的サイト公開のサービスによってはビルド回数の制限を喰らいます。
そもそも、個人サイトや小規模サイトでは多くても一日一回が更新の目安だと思うので、毎日深夜にビルドで十分では無いでしょうか？というのが自分の考えでして、だからこそ方法 1 にしようと思った次第です。
方法 2：GitHub Actions で新規記事のブランチを特定の時刻にマージする
実は、仕方なく書いた手法であり、指定時刻にマージするのは基本的にふさわしくないです。他に手段がなかった場合の最終手段のイメージです。
ブランチごとに記事のデータのみ変更を持ち、マージ先のブランチで記事データを取り込んでビルドすることで予約投稿となります。
方法 1 とは異なり、時間指定も上手にしやすいです。毎時ビルドなど不要だからです。
しかし、GitHub Actions で予約時刻にビルドするのは外部のライブラリに依存しなくては実装できないため、長期的に使えないことを想定する必要があります。
その観点でも方法 1 がふさわしいでしょう。
そもそも予約投稿は必要か？
本質になりますが、僕個人としては必要だと思っています、というか必要性を感じています。
理由はいくつかあります。
- 非効率である
- 必要な理由がある
手動で特定の日時に更新するのは非効率です。GitHub に毎回 Push するのは、コマンド一個で出来ても PC を起動する点で面倒です。特に、静的なサイトではなおさら。
必要な理由は、長期的に記事を更新できない事情がたまにあるからです。
まとめて書いて貯めておくことで、更新作業はしなくても更新してくれます。出先などでは非常に便利。
おわりに
方法の提案でした、お読みいただきありがとうございました。