TeQA ティーカにつめこんだ技術スタック

TeQA はエンジニア向けのスキルシェアマッチングサービスです。エンジニアの持つ「ちょっとここを相談したい」という課題を 15 分 1 セッションで相談できるサービスです。Zoom や Slack などを必要とせず、リアルタイムな双方向コミュニケーションがサイト上で完結するという今までにないスキルシェアリングサービスです。このサービスを実現するにあたって、SNS 的機能、音声通話、スクリーンシェアなど、普通の Web サイトでは実現できないような機能をたくさん実装する必要がありました。現在エンジニア二人で開発している手作りサービスですが、どのような技術スタックでこのようなサービスが実現できるのか、ご紹介したいと思います。

ウェブフロントエンド React

まず、Web のフロントエンドには React を採用しています。React は現在 JavaScript でのフロントエンド開発の約 80% を占めているので、ほぼデファクト扱いで利用を開始しました。(https://2020.stateofjs.com/en-US/)
開発メンバーは React はおろか、Web のフロントエンドの開発は初めてでしたので今でも試行錯誤の毎日です。なお、Redux は使わず、hook をできるだけ利用するようにしていますが、state のバケツリレーがだんだんしんどくなってきています。このあたりは最初にディレクションをきっちりきめないとあとで苦しくなります。ものすごく個人的な少人数開発でのオススメは hook を全力活用で redux 非採用です。

バックエンド AWS API Gateway + Node.js

バックエンドの API は AWS の API Gateway を Node.js で記述しています。また、デプロイを自動化する部分の手間が惜しかったので Serverless Framework を使ってデプロイの簡略化、オフライン実行を実現しています。なお、TeQA のような SNS 的な要素のあるアプリを開発する場合は、GraphQA が使える AWS AppSync を利用することで関連データの取得や(AWS Amplify を使った)画面リフレッシュ等も容易になりますので、そちらを強く推奨します。私達が開発を始めた時点では AppSync の存在を私が知らなかったのでそこは少し後悔しているところです。

クラウド AWS

上記でも少し述べましたが、バックエンドはすべて AWS で構築しています。AWS で利用しているサービスはすべて Infrastructure as Code + Serverless architecture の概念で構築していて、手作業での管理を(ほぼ)排除しています。下記に TeQA で利用している主な AWS のマネージドサービスとその用途一覧を記載します。

- DynamoDB : メインのデータベースとして利用

- S3 : React アプリのデプロイ先、質問の添付画像、プロフィール画像等

- Cognito : ユーザー認証

- API Gateway : RESTFul API、WebSockets の提供

- Lambda : API Gateway と連携した API 実装、ElasticSearch と DynamoDB の同期等

- ElasticSearch Service : DynamoDB はクエリが弱いので、質問トピックやユーザーの検索等に使用

- CloudFront : Web ページのキャッシュ

- Route 53 : teqa.net ドメインの管理

開発言語 TypeScript

まず、フロントエンドは JavaScript、バックエンドには Node.js を利用しているということから、TypeScript の利用が候補に上がりました。開発を始めた当初は、型の必要性を甘く見ていましたが、少人数開発においてもやはり変数等の意図を取り間違えたりするバグが多く発生しました。これから開発を始める方は最初から JavaScript ではなくて TypeScript を導入することを強くオススメします。

リアルタイム通信 WebSockets

オンデマンドマッチング機能を実現するためには、リアルタイム通信が必要になります。これは WebSockets を使って実装しました。なお、WebSockets は API Gateway を使って提供できますので、これも API Gateway + Node.js の組み合わせで実装されています。React 上で WebSockets 受信時に state 管理をするのはかなり複雑になってしまうので、hook 等を積極的に利用して WebSockets による state 更新処理をシンプルに記載するようにするのがよいと思います。

WebRTC(画面シェア) Twilio

Twilio はかなりメジャーな WebRTC サービスで、SDK も充実しているため採用を決定しました。ピアツーピアの通信の場合 $0.0015 / 1 分 * 参加者 という価格で利用できます。なお、ビデオの録画が必要な場合は video room の作成が必要になり、$0.004 に跳ね上がるため現在 TeQA では画面シェアの録画機能は提供していません。参考 URL https://www.twilio.com/ja/video/pricing

なお、現在 AWS は Amazon Chime という類似サービスを提供しており、類似の価格帯かつ AWS で完結できるため、もし今から開発するのであれば Amazon Chime を利用した可能性が高いです。

クレジットカード支払い/銀行振込 Stripe

TeQA では、質問したい人がクレジットカードで支払いを行い、質問に答えた人が売上をためて、一定金額以上で銀行振込が可能になります。支払い情報の安全性と高速な開発の両立のため、Stripe を採用しました。Stripe Payment という仕組みで支払いを受け付け、Stripe Connect という仕組みで売上の管理、銀行振込を実現しています。そのため、TeQA では一切ユーザー様の支払い関連の情報を保持しておりません。
Stripe は API とドキュメントがかなり充実していますので、開発する際はよく読み込めばそんなにハマることはありません。ただ、手数料周りが複雑で、読み違えるとビジネスモデル自体が成り立たなくなるので気をつけましょう。私が出金手数料について勘違いしていたため、実際に大幅な実装変更を余儀なくされました。

デスクトップアプリ開発 Electron(ボツ)

実は TeQA の開発は一旦 Web アプリとしてスタートし、途中で一度 Desktop アプリに移行しています。というのも、画面シェア中に相手の画面をコントロールしたり、画面上にペンで書き込みをするような処理を行うのに Desktop アプリの権限が必要だったからです。これによって、よりスムーズな課題解決セッションが実現できると信じていました。が、実際には Web アプリからデスクトップアプリをダウンロードしてもらえる可能性が低く、かつ開発リソースも分散してしまうので、現在は Web アプリ一本での開発に戻り、Electron の採用はボツとなりました。

まとめ

技術をモリモリに詰め込んでいますが、AWS や 3rd パーティのサービスを上手く組み合わせることで一応 2 人の開発規模でもサービス開発ができることがわかります。ただし、ビジネス的な観点で考えると、開発チームの規模が小さい、スキルが図抜けていないような場合はあまり開発リソースを割かなくて済むようなシンプルなビジネスモデルを追求することをおすすめします。たとえば、LP や No Code で実現できるならそれがベターです。エンジニアのひとはすぐにイケてる技術を詰め込みたくなるのでこの辺は自戒も込めて。