こちらの記事は、今後のシステム開発で経過に応じて、随時編集・追記します。

プロバイダーのホームページ領域を有効活用するため、フォトアルバムでも設置しようかと考えている。

まぁ「フリーのCGIとかプログラムを導入すれば、いいんじゃね」というレベルの、とてもありがちなシステムをつもりなんだが、それら「吊るし」のシステムだと、自分が契約している Web サーバ領域を有効利用するためには、仕様・環境などの条件がイマイチ合致しない。

特に問題となるのがこれ。

@nifty ホームページサービス ミニプラン

そう。
公開ページの設置を予定しているこのWeb領域が、曲者。
もともとは、老舗の「@nifty @homepege」の後継で、先代で提供されていた機能を、最低限継承した代物。

なので、Perl は使えたりするものの、5.8.7 と古かったりとか、一部の標準モジュールが使えなかったりする。
PHP も、このプランでは使えない。

別の記事でも書いたが、上位プランに変更することにより、PHP やデータベースが利用できるようになるのだが、料金や自由度を考えると、別会社のプランを検討する。

確かに巷の Perl CGI を探してきて、それを改造して無理矢理動かすというのも一案。
しかしながら、それだと楽しくないし、そもそも巷の Perl CGI も、かなり前に作られたものが多く、レガシーな作り物が多い。

そんなこんなの理由で、昨今のスタンダードな Web システムの実装とレガシーなサーバ環境の共存を研究する目的で、フルスクラッチしてみることにした。

システム構成

ありがちな「公開系」と「管理系」の２構成。

フロントエンド（公開系）

サーバは「@nifty ホームページサービス」
Web コンテンツは「Perl (CGI) + Vue.js (CDN)」で実装。

こちらは「見せるだけ」の機能に特化して、複雑な処理は走らせない。
というか、制限付き CGI （Perl 旧バージョン＋標準モジュール一部欠け）をゴリゴリ開発する気は、更々ない。

Vue.js を利用するものの、フレームワークというよりは、結果セットのフィルタリングやソート時のエフェクト用途で利用する感じ。
ほぼ「受け身」のシステムなので、この程度の簡単な環境で構築。

バックオフィス（管理系）

サーバは「さくらの VPS」
Web コンテンツは「Laravel (PHP) + Vue.js（Laravel のUI として利用）」

こちらは管理機能を実装するため、Web システムとしてはガチ。
とはいえ、昨今の Web システムでは、割とスタンダードな環境。

公開系と管理系、「さくらの VPS」で構築すれば楽じゃね？

確かにそうなんだけども。
でも、元々「さくらの VPS」は、非公開系のサーバとして運用しているという個人的な事情と、公開系と管理系を同居させることによるセキュリティ面の配慮で分けた次第。
また「レガシーな Web 領域（＝@nifty ホームページサービス）を有効利用する」という命題に応えるため、このような環境にした次第。

重要な考慮すべき部分

バックオフィス⇒フロントエンドの同期

データの追加・更新・削除の都度、キューを作成し、それを非同期バッチにて処理する事によってデータの内容をフロント側に反映することで同期する。

クラッシュ対策（バックアップ）

システム基盤（プログラムソース）については、別途バックアップする（というか、Git に保管しておく）のが前提。
ここで言うのは、データの話。

ちなみに、この Git リポジトリ。PostHook で別サーバに Fetch してるので、リポジトリ自体も複数保存している。

公開系

もともとデータはすべて「管理系」に保持していて、そこから抽出・アップロードされるため、クラッシュしても、データは「管理系」のほうから再度抽出することでリカバリ可能とする。

管理系

データについては、日毎のバックアップをバッチ処理し、バックアップサーバ（ストレージ）に転送する。

考えていること

データ連携

最初はこんな感じで考えていたのだが、もしかしたら Perl の簡易データベース（dbmopen など）が使える可能性があるので、利用可能であれば、その形式に寄せるつもり。

画像

閲覧用画像データには、コピーライトの埋め込みで、以下の候補を検討中。(TBD)

• ウォーターマーク ⇒ ImageMagic で可能だが、簡単に消せる。
• 電子透かし ⇒ できればこっちを考えている。
  ステガノグラフィーが主流だと思うけど、技術的に標準化されてないので、できれば標準的なのが使いたい。