upinetree's memo

Web系技術の話題とかたまに日常も。Qiita: http://qiita.com/upinetree

自分の結婚式用にサーバレスな招待状Webアプリを作った

結婚しました

2018/12/1 (土) に結婚式を行いました。天候に恵まれ、穏やかな晴れの日で式を挙げられて本当に良かったです。私のことなので直前で体調を崩すか怪我をするか天気が崩れるかのどれかはあるんじゃないかと思っていたのですが、何もなく無事に終えることができて安心しました。

我々夫婦のために多くの方々が集まってくれてとても嬉しかったです。遠くからはるばる来てくださった方もいて、本当にありがたい限りです。

よちよち.rb からも電報をいただいてしまってびっくりしました。 curl から始まり | ruby で終わる電報をいただく(そして困惑する司会の方がゲストに促されそれを読み上げる)機会はそうそうないでしょう 😂 お忙しい中、粋な計らいをありがとうございました。

披露宴の内容やアイテムにはかなりこだわって、我々らしいオリジナリティのある結婚式になったと思います。夫婦で演奏したりもしました(私がギター、妻が鍵盤ハーモニカ、ヴィブラフォンマリンバ)し、謝辞にLTしたりもしました。

現場Rails本の執筆と並行しての準備となってしまってかなりきつかったけど、妻に主導してもらってなんとかなりました。本当に感謝。そしてようやく締切に追われない日々が訪れ、ブログを書くこともできるようになりました。

これから夫婦ともどもよろしくお願いいたします。

(というわけで例のリストです)

http://amzn.asia/0Ly1XAG

招待状Webアプリ

結婚式のこだわりのひとつとして、招待状の回答をWebアプリでできるようにしてみました。せっかくなのでその紹介を書いてみようと思います。

なぜ招待状の回答をWebアプリでできるようにしたかというと、従来のはがきでの回答には以下の扱いづらさがあったからです。

  • 「御」を打ち消したりといったマナーがたくさん。ゲストに手間をかけさせたくない
  • 当日の情報を見たいときにすぐ見られない。地図の検索などの一手間が必要
  • 返信用切手の購入や添付が必要
  • 回答の集計が手入力で大変

一方で、はがきには紙の良さもあります。色々とデコったり、文字でメッセージを伝えたいといった需要もありますし、モノとして手元に残るのはうれしい点です。

そこで、今回は以下のような運用にしてみました。

  1. 招待状は紙で送付。ゲストカードと、招待状アプリの案内カードを同封
  2. 招待状アプリの案内カードには、アクセスするためのQRコードと、ログインパスコードを記載
  3. 招待状アプリで回答していただく
  4. こちらが集計スクリプトで回答結果をチェック(毎日のたのしみ)

QRコードの用意やログインパスコードの添付など、物理との接続のための工夫はかなり苦労しました。正直この作業中ははがきのほうが数倍楽だったのではとも思いましたが、苦労した分だけ楽しみつつも総合的に満足できるものができたかなと思っています。

アプリケーションの構成

公開用に個人情報とか抜いたリポジトリを作ってみました。

https://github.com/upinetree/wedat-demo

今回は前々から興味があったサーバーレスSPAでやってみました。AWSを中心に以下のような構成にしました。

  • リソースは S3
  • 回答結果を DynamoDB に保存
  • API Gateway で DynamoDB にアクセス
  • 認証は Cognito
  • ネットワーク周り
    • CloudFront
    • Lambda@Edge (テスト環境のBasic認証用)
    • Route 53
    • Amazon Certificate Manager

なお、これらの構成は Terraform で管理しました(勢いでかなり雑に…)。

今回はSPAということで、フロント周りはReactで組みました。CRAでシュッと作って、その上に以下の色々を乗せた感じです。

  • Redux
  • Redux Form
  • React Router
  • React Transition Group
  • Luxon
  • Styled Components
  • Tailwind CSS
  • AWS Ampify

なお、CRAの Service worker は途中まで使ったり整備したりしたのですが、キャッシュの更新とかの懸念点の解消が公開に間に合わず、泣く泣く外しました…。

作ってからCRAもAmplifyもかなり大きなアップデートが入っていて、追従できていないのも心残りではあります。作って利用してもらうことが最優先だったので、目的は達成できたということで良しとしています。

やってみた感想

Webアプリにしてみて感じたのは

  • 紙面のような限界がないので、長文でコメントくれる人も結構いてうれしかった
  • 結構びっくりしてもらえた。製品かと思わせることに成功
  • 集計がめっちゃ楽。毎日集計結果とメッセージを確認できるのでモチベーションになる
  • ゲストに名前を入力してもらうので、名前の正確な漢字に手書きよりも確実に気付ける

のあたり。やってよかったな〜と思いました。

技術的な感想としては

  • サーバレスSPAめっちゃ低コストで月に多くて100円程度しかかからない。運用もほとんど気にしなくていい(一応トラッキングはしていたが、安定してからは本当に手が離せて助かった)
  • CRAやAmplifyのレールからはずれたいときに大変だった。結局ソースコードを読みに行った
  • Amplifyが提供するReactコンポーネントはカスタマイズがあまりできなくて、上書きしたりしたり、同じような機能を持つコンポーネントを自作したりした
  • Styled Components 最高だ。Tailwind CSS でざっくりマークアップして、まとまりがでてきたらコンポーネント化するというパターンがかっちりきた
  • API Gateway でとても苦労した。Terraformでの管理が一つ一つのリソースに対して記述量が多くて大変だった。マッピングテンプレートのVTL (Velocity Template Luangage) の記述方法でもめっちゃハマる。これでサーバーレスで柔軟なエンドポイントを定義できると考えて、トレードオフとしてはありのようななしのような…?代替手段があればまずそっちを選択すると思う
  • Cognito もちょっとレールからはずれた使い方をするととたんに応用が効かなくて苦労した。次は Auth0 とか Firebase auth とかも使ってみたい
  • (最終的には採用しなかったけど)Service worker は、キャッシュの扱いで苦労した。キャッシュはCDNにあるのかSWにあるのかブラウザにあるのか、どこの設定が効いているのか、というところ。この規模のアプリのSWキャッシュでそんなに苦労に見合うメリットはないと判断した
  • それぞれのサービスやフレームワークを組み合わせたベストプラクティスがなくて、その都度自分で判断しないといけなかったのは大変だったけど楽しかった。普段書いてるRailsは(レールに乗っていれば)だいぶ楽できるなと再確認

技術的な方はその都度アウトプットできたら良かったのですが、執筆という巨大なアウトプットの最中で断念しました。まだ使える知識がありそうだったらこれから出してみようかと思います。