レポートを書くのが遅くなって申し訳ない。
7月14日に新潟市で行われたNiigata Engineer Meeting #8にお呼びいただきまして、
SPAについてお話ししてきました。
今回初めて登壇のオファーをもらってお邪魔したのですが、不慣れなアウェイ感からかド緊張。
思うように話せなかったということでかなり反省しております。。
※緊張から写真を全く撮っていなかったので載せれるものはありません。。
これからはじめるシングルページアプリケーション
今までにSPA開発経験がなくて、これからSPA実装を始めたい人をターゲットに初心者向けの内容をお話しました。
会場で手を挙げてもらった感じ、狙ったレベルの方が多くて一安心。
なんですが、45分時間もらってて事前の練習ではいい感じだと思っていたんですけど、
緊張からからどうしても早口・途中で内容を端折る（飛ぶ）ことが多くて30分ほどで終わってしまいました。（汗汗汗）
こういうとこなんだよ、、w
というわけで、以下内容をざっくり。
- SPAはページの一部分を書き換えるんじゃ
- そうするとページの更新が速くなるのじゃ
- SPAは読み込み直さないからフロントでいろいろやる
- 基本Ajaxでやり取り
- サーバーはView考えなくて良い
- メリット
- UXが向上する
- 見た目サクサク動く
- ネイティブアプリの代わりになり得る
- デメリット
- 初期ロード長い
- 実装大変
- 最近事例いっぱいある
- GoogleさんほとんどSPA
- あとチャットサービスとか
- SNSとか
- 仮想通貨取引所とか（個人的に面白い領域）
- 向いてるアプリ
- 滞在時間長いやつ
- データ操作するとか管理画面とかのやつ
- 最近業務アプリのやつをSPAで作り直すことが多いよ
- 向いてないアプリ
- 直帰率高いサイト（主にブログ）
- コーポレートでやる必要ある？
- ゲーム開発は専用ライブラリ使っとけ
- 基準
- 開発アプリケーションの特性を理解する
- 開発体制確保できる？
- フロント一人とかキツい
- フロントエンド開発構成
- React, Angular, Vue.jsじゃ！
- サーバー開発構成
- WAFならなんでもいい
- WordPressとか外部APIでもいい
- APIを用意できればいい
- 組み合わせ自由
- 慣れてるの使え
- フロントエンドの共通知識
- コンポーネント指向じゃ！
- コンポーネントは状態・機能を持った部品なんじゃ
- 部品の組み合わせでページを構成するじゃ
- 利点
- 再利用性（亜種がいっぱい増えるのを防げる）
- 外からデータ・機能を付与可能
- 状態持てる（コンポーネントの内部状態を切り替えて見た目を変えるとか）
- コードをカプセル化できる
- 各ライブラリ・フレームワークの公式チュートリアルおすすめ
- 自分のアイデアで何か作ると理解早いよ
- まとめると
- SPAはページの一部を更新するんじゃ
- フロント実装は工数増えるんじゃ
- サイトに長くいるサービスに向いとるんじゃ
- 実装者確保しとくんじゃ
- フロントとサーバー側の組み合わせは自由じゃ
- コンポーネントを頭に叩き込むんじゃ
質問
今回質問が多かったんですよね。
というか、45分で網羅できるものではなかったので、あとで勝手に納得しましたが。
その1: デザイナ、SPA開発者、バックエンド（API）のコミュニケーションはどうする？
A. アジャイルで開発していくことがほとんどなので、毎日とか週1とかで時間を決めて定期的に打ち合わせを密にやるのと、チャットなんかですぐ聞いちゃうのがいい。
ここで、わからないことをずっと抱えてると全体に関わるので、すぐ共有したほうが◎。
その2: SPAは業務アプリに適しているっていうけど、IE対応は？
A. 最近はIE11にだけ対応すれば良いので、フレームワークが対応していて対応可能。
しかしIEは負債。
その3: 業務アプリはいれたら3年5年更新が難しい場合があるけど、JS界の早いバージョンアップにどう合わせていけばいい？
A. 作って終わりのケースが多い。何かあれば追加で対応しますという感じで。
継続的に開発していくので無いなら、諦めて2〜3年で作り直すのが吉だと思う。
その4: 前にデータの数が多い時DOM描画が重くなるときがあったけど最近はどうか？？
A. DOM生成の内容による。テキストだけなのか、画像ありなのか、など。Google スプレッドシートのように、（バーチャルスクロール？だっけか？）見えるところだけテーブルセルを生成するみたいなのは有効。（ハードルクソ高い）
サーバー側の最適化も考慮に。
その5: コンポーネントがデータを持ちすぎてステートがパンクすることはあるか？
A. ほとんどない。けど、base64化されたData URIとかは重くなるよ（メモリ的に）。イベントハンドラの削除忘れとかメモリの心配をしたほうが良い。
その6: フロント側のテストとかはしなければいけない？
A. フロントのテストは書かなければいけないわけではない。ほとんどの場合、書かないことが多い。時間が足りない、チームのスキルが足らないなど。テスト書けるのが一番望ましいけども。
その7: ECにはマッチするのか？
A. 商品紹介ページなどはマッチすると思う。部分的な適用もありだと思う。
その8: ページ遷移しないけどアナリティクスの設定とかはどうするのか？
A. フロント側でページを切り替える処理があるので、そこでアナリティクスのAPIを個別に呼び出してカウントする。※参考記事参照。
その9: サーバAPI実装などで情報を共有するのはどうすればいいか？
A. API情報はSwaggerなどを利用してAPIドキュメントを用意する。細かいのはGithubのWikiなどで共有。
その10: SPA自体の事例は増えているか？
A. 増えている。業務アプリを作り変える場合は大体SPAでは。Web制作界隈もSPA案件が増えている。地方はこれからでは。
その11: これからSPAはどうなるか？
A. 個人の主観だけど、これからもっと楽な構築方法が出てくるのではないかと思う。フレームワークがあるからとはいえ、結構辛いところもある。
あわせてWebフロントエンドのディープさが増すのも確か。
県民のための きょうから始めるAWS
AWSのお話をしてくれたのは、いつも上越でお世話になっている植木さん。
県民のためにAWSの初歩を解説してくれました。
しかし、どうも参加者の皆さんはAWSを結構使っているらしく、物足りない様子でした。
最新動向とかのほうが面白かったのかな〜。
個人的に、Microsoftめっちゃ頑張ってるというのが参考になりました。
近年のMSは目を見張るものがあるっす。
植木さんには今度上越で思う存分力を発揮してもらいたいなという願望が高まっております。
今回の感想
ぼくの話はSPAに詳しくない人には参考になったのではないかと思ってます。
地方ではブームが遅れてやってくるので、そろそろ本腰入れて取り組んだほうが良いんじゃないでしょうかね。ただし、無理にSPAにする必要はないので、部分的にだったり、難しそうだったら諦めるのも手です。
反対にすでに知ってる人には物足りなかったはず。
ディープな世界を思いっきり話す場とかがあると面白いですよね。（NDSさんかな）
誰かやらないかな。上越TechMeetupでやろうかな。
ということで、新潟市の方々にお会いできて楽しい時間でした！