「Live Channel」リリースに寄せて

※「Live Channel」開発時の画面です。

こんにちは。たいしょうです。
アドベントカレンダーよろしくきっと誰か次の記事を今月中に書いてくれるだろうと期待に胸を膨らませています。誰とは言いません。

「Live Channel」について

さて、先日(すでに2ヶ月前になってしまってますが)HAROiDではライブ配信ソリューション「Live Channel」の提供開始を発表しており、すでにいくつかの案件においても、このプロダクトの導入が行われております。

この「Live Channel」は主にインターネット上でのライブ配信からの各種メディアへのリーチ・新規ユーザーの獲得を実現することが可能なインターネットライブ配信プロダクトです。

とりわけネットファースト層においては、とても親しみがあるライブ配信という形を企画へ取り入れることで、今までコンテンツに接触していなかった層が興味・関心を抱くきっかけを作り出すことが可能となっております。
  

「Live Channel」における開発について

開発体制

このプロダクトの開発においては現在はフロントエンドエンジニアの私と奥谷氏の2名体制で主に開発を行っており、サーバーサイドに関しては、今までに提供されているHAROiDプラットフォームの機能のみで完結できるように開発を実施しています。

技術スタック

「Live Channel」で新規に開発している部分について、大まかには

<フロントエンド>

  • React
  • Redux
  • Lodash
  • Stylus
  • Pug
  • TypeScript
  • gulp

です。基本的にこのセットでだいたいのSPAは実装できるのではないかと思われます。インフラは

<インフラ>

  • S3
  • CloudFront
  • Route53
  • Cognito
  • Lambda
  • API Gateway

上の3つはコンテンツの配信用です。下の3つは管理画面などの認証などで利用しています。

フロントエンドの技術選定の理由に関しては

  • React/Reduxでの開発に慣れていること。
  • どちらかが作業ができない状況になった場合でもケアできること
  • 画面間でのデータの持ち回りやポーリングの同期ロジックが激しく実行される想定なのでSPAがいいと結論付けたこと
  • デプロイ方式の都合上(思考停止で)通信ロジックを分離できるreduxが最適だと結論したこと(後述)
  • アニメーション周りの演出や非同期のポーリングについてもすでにreact/redux内で作りきれる知見を持っていること

以上の理由でこんな感じの選定になりました。

開発中に新たに試みたこと

👍1つのリポジトリ内ですべての配信プロジェクトのリソースを管理

各環境へのビルドとデプロイはGitlab CIを使って行ってますが、同一ドメイン上にプロジェクト用にアレンジしたソースコードをデプロイ(livech.jp/aaa用とlivech.jp/bbb用では別々のコードを使用)する必要があったため、ブランチの命名規則を作り、それに対応した環境とディレクトリへデプロイできるようにした(例えばhogege/aaaブランチの場合hogege環境の/aaa直下へデプロイできる)。

👍各配信プロジェクトごとの管理画面アクセスに対するユーザー認証周りをAWS側に寄せた(寄せている)

各配信において進行管理などの管理画面を用意していますが、各配信プロジェクトに対して横断的なアクセスができないようにするためにユーザー認証機能が必要になってきます。そちらに関して今回は極力(厳密にはプラットフォーム使っているのでサーバーレスなわけがない)サーバーレスでの対応を目標にしているのでそのへんを解決するものとしてAWS Cognitoによるユーザー認証機能の実装を行っています。

👎CSS GRID Layoutで頑張った結果、IE11に敗北した

Autoprefixerでなんとか対応できんもんかと前半戦頑張って見ましたが、やはり動的な要素数になってしまうとAutoprefixerではまかないきれない部分が往々にして存在するため悔し涙を飲みました。やはりまだIE11に対して煮え湯を飲まざるを得ない部分はあるのだなと改めて認識。最終的に安定のdisplay:table float:left

これからも引き続き試行錯誤しながらライブチャンネルの機能拡充や安定運用のための方策を練り込んで行きたいと思ってます。

We are hiring!
HAROiD の採用情報
フロントエンドでSPAをがしがし作りたい方ぜひお越しくださいませ。