ID:76234さん

自社プロダクトの機能でビデオ通話機能があり、 これまでskywayというプロバイダーを使って、実装されていたが、通話時の安定性やログの詳細の検知ができるという観点からagoraというプロバイダーに切り替えることになり、その切り替え作業を自社で作成されたパッケージを使って置き換えた。 自社ではappにもビデオ通話基盤が使われているのでappはreact-nativeを使っており、react-native-agoraというパッケージを使って基盤を移行した。 # プロジェクト概要 ビデオ通話基盤移行 自社のオンライン診療アプリケーションで診察を申し込んだ患者と医療機関で診察を行うためのビデオ通話を用意していて、 セキュリティや品質の観点からビデオ通話のプロバイダーをagoraに切り替える必要がある。 かつビデオ通話を行うためのプロバイダーがプロダクトによって異なる場合があり、プロバイダーに依存することなく、クライアントからプロバイダーのサーバーに接続することができるように自社でクライアント用のパッケージ(call-lib)とプロバイダーに接続するためのトークンを発行するサーバー（call-reg）を管理しているがこれらのリアーキテクチャを行う。 # チーム情報 エンジニア　1人（私） ビデオ通話基盤チームエンジニア（1人） # 開発・実装内容A 【概要】 医療機関webアプリケーションと患者webアプリケーションに自社で提供しているプロバイダーからビデオ通話に接続するためのトークン発行とプロバイダー接続を行うためのパッケージ（call-libと呼ぶ）の組み込み 【どのような機能の開発・実装か】 call-libをangularアプリケーションとnextjsアプリケーションに組み込み 【課題・問題点】 実装していく中でアプリケーションサーバーから取得したtokenをもとにcall-regからプロバイダーに接続をするためのトークンを取得したにも関わらず、通話ルームに入ると画面が真っ白になって相手のしか聞こえない問題があったが、ビデオ通話基盤チームと連携しながら解決していった。 具体的にはnextjsアプリケーションで通話ルームページをレンダリングする際に診察に関わるデータが クライアントサイドレンダリングで表示しようとするがロード中に、call-libがcall-regから取得したトークンをもとにプロバイダーに接続して通話画面を読み込もうとすると、画面のレンダリングが正常に行われなかった。 【打ち手・使用した技術】 そこで診察に関わるデータを読み込んだ後にcall-libのインターフェースとして提供されているProviderコンポーネントをnextjsのdynamic importで遅延読み込みをして通話画面が読み込めるようにした。 # 開発・実装内容B 【概要】 患者appにビデオ通話に接続するためのトークン発行とプロバイダー接続を行うためのロジックを追加 フレームワークがreact-nativeで、react-native用の自社でプロバイダー接続するためのパッケージを作っていないので パッケージ内部で行っている処理を自前で実装。 【どのような機能の開発・実装か】 1 クライアントからcall-regにリクエストするためのjwtトークンをアプリケーションサーバーから取得するリクエストの処理を追加 2 call-regのエンドポイントにjwtトークンを含めた状態で、プロバイダーに接続するためのトークンを返すリクエストの処理を追加 3 トークンをreact-naitve-agoraというagoraのビデオ通話画面のインターフェースに渡して実際にビデオ通話の疎通ができるようにする。 【課題・問題点】 自前で実装するところもあり、ビデオ通話疎通時の、コネクションの状態をapp上で取得する方法がなく実装に難航した課題があった。 【打ち手・使用した技術】 ビデオ通話基盤エンジニアとして協力してsocket.client.ioを使って実装する形で解決した。

# プロジェクト概要 「こどもとわ」というスポーツが上手くなりたいけど、教えてくれる人が近くにいない子供をターゲットにしたコーチとのマッチングサービスを開発している。 知人のエンジニアの二人で、立ち上げたサービスでスポーツが上手くなりたいけど教えてくれる人が近くにいない、子供むけにサービス上に登録されたコーチから自分に合うコーチを探して、所定の時間に決められた場所で教えてもらえるというのをコンセプトにしている。 エンジニアが私と知人の二人で、カスタマーサポートなどもしていただいている経営者の方の３人で運営している。 https://portal.kodomotowa.com/ # チーム情報 エンジニア　2人 ceo 1人 # 開発・実装内容A 【概要】 stripeの審査通過、審査落ちした該当のユーザーをslackに通知、審査状況に関して該当のユーザーに自動でメール送信するような仕組みを構築した。 【どのような機能の開発・実装か】 stripe申請したユーザーの審査状況をslackで検知、かつ審査の合否に関わらず、ユーザーに周知のメールを自動で送信するように 【課題・問題点】 子供にスポーツを教えるコーチに収益が入るビジネスモデルなので、コーチをしてもらうユーザーにはstripe登録をしてもらう必要がある。 そのため、stripeに登録するための個人情報を申請してもらい、stripeの審査状況をこちらがわで確認して、不足書類や審査に通った旨を連絡する運用が発生する。 審査状況の確認は逐一stripeのdashboardで確認する必要があったり、審査の完了や審査落ちの場合の必要書類の通知などのコーチへの連絡をメールで手入力で送る形になっており、リソースが少ないこともあり審査状況の確認と審査状況に関するコーチへの周知を自動化する必要があった。 【打ち手・使用した技術】 ruby on rails stripe webhook railsのactivejob stripeは登録した連結アカウントのアカウント情報を審査状況などが更新するとwebhookで指定したエンドポイントにイベントを送信して最新のアカウント情報をアプリケーション上で検知できる仕組みがあったので、account.updatedというstripeのアカウント情報に関わるイベントに関するwebhookを使ってrailsで設定したエンドポイントに、イベントを送信するようにした。 審査状況に関するstatusが完了になっていたらアプリケーション上のデータベースで保持しているcoachテーブルのstatusを完了に更新して、自動で審査完了メールを該当のユーザーに送るのと、slackに通知してリアルタイムでユーザーへの通知と自社での検知が行えるようにして、運用コストを軽減した。 審査落ちに関しては、 1 stripeで提供している書類登録フォームで全て登録した上で申請までしたけど提出した書類に不備があり、審査に落ちた 2 stripeの書類登録フォームの入力が途中までしかされていなく、stripeのdashaboard上でアカウントは登録されているけど申請まで完了していない の二つがあり1はstripe webhookのcapability.updatedというstripeを使える要件である、支払い可能、送金、　入金ステータスを見るイベントがあり、これを使って、stripeの審査落ちを検知して、ユーザーに審査落ちの旨をメールで自動送信するようにした。 2はstripeの登録フォームが途中まで入力されていないかどうかをstripe webhookで見分けることが難しいのでアプリケーションの仕様上、コーチ登録をするための必要情報をアプリケーション上でも入力してもらった上でstripe登録フォームにリダイレクトするため そのタイミングで24時間後に実行されるジョブを仕込み 申請完了か否かのステータスをcoachテーブルに保持していることから 24時間後に申請完了のステータスになっていない場合は、登録のリマインドメールを送るようにしている。