HiTTOを支える技術について (バックエンド編)
HiTTO株式会社のプロダクトチームでエンジニアをしているhongoです。 今日はHiTTOのバックエンドで使っている技術を紹介したいと思います。
言語
Scalaを使っています！
HiTTOはリニューアル版として新しく作っているプロダクトで旧版はhitTOという名前なんですが、hitTOはPHPで作られていてかなり技術負債が溜まっている状態でした。そこで新しくリニューアル版を作るにあたって、どんどん成長しているプロダクトということもあり今後のスケールを見越してPHPの採用はせず、保守性やパフォーマンスに優れたScalaを採用しました。
と、書きましたがメンバーにScalaが好きだったり得意なメンバーが多かったことが使っている大きな理由ですw
技術面・採用面のメリット・デメリットはどんな言語にもありますが、メンバーが書いてて楽しいというのはすごく大事なんじゃないかと思います。そして母数は少ないものの特徴的で熱狂的なファンが多いのもScalaの特徴かと思うので、楽しいとかチャレンジしたいとかそういう人が集まって、いいプロダクトができたらいいなぁと思います。Scala楽しいヨ！
フレームワーク
PlayFrameworkを使っていますが、GraphQLを使っているのでリクエストを受けた後はSangriaというライブラリで処理される感じになってます。SangriaはScalaで書いたGraphQLのスキーマがそのままGraphQLのスキーマファイルとして出力されるのでメンテナンスが楽だったり、色々と型安全になったりマクロが用意してあったりと、よくできているライブラリで便利に使わせてもらっています。
GraphQLを採用した理由としては、フロントをSPAで作っていて1ページでたくさんのAPIを叩かなくて済むというのが大きいんですが必要なものだけ取得できるしグラフになってて実際のとこ便利だなぁと思っています。
アーキテクチャ
CleanArchitectureの考え方で作っています。どこで何を書くのか、そこの責務は何か、など大枠の層を決めて流れを図にして整理しながら作っています。 例えばInfrastructureの層ではDBやAPIなど外へアクセスを担当するだったり、UseCaseの層ではEntityやInfrastructureのインターフェイスなどを呼び出して処理の流れを書くといった決めにしています。
(↓はざっくり流れの図です)
CleanArchitectureの採用理由ですが、別に整理できればオニオンでなんでもよかったんですがボブおじさんの本があるので参考にするものがあっていいかもなぁというのもありました。
単体テスト
ScalaTestで書いていて、CleanArchitectureの各層の責務に合った内容のテストを書いています。
例えばInfrastructureの層であれば実際にSQLを実行してのテストを書いたり、UseCaseの層であれば処理の流れが期待したものかをテストしたりしています。
各層で閉じたテストができるようにDIしている部分をモックに差し替えて、その層の責務じゃない部分はテストしないでいいようにしています。
CI/CD
CIはCircleCIで行っていて、単体テストやscalafmt/scalafixでのフォーマットチェック、GraphQLのスキーマ生成などを行っています。
CDはPullRequestベースでdevelopやmasterにマージした時デプロイが走る形になっています。インフラの話で詳しく書くことになると思いますが、ECRやECSを使っているのでデプロイでその辺りにも更新がかかります。
外部サービス
DataDog
アプリケーションのログなどはDataDogに流してみれるようにしてあります。通知や検索など多機能で便利です。
SendGrid
サービスの特性上、多機能なメール送信サービスが必要だったのでSendGridを使っています。例えば一度に複数件送信できる機能だったり、メール開封イベントのリクエストを投げてくれる機能を使っています。
リファクタリング
いつの間にか肥大化したり冗長になってたりとか、アーキテクチャの構成ちょっと変えた方がいいかもみたいなことはありがちだと思いますが、スプリントに改善のタスクを積むので少しずつよくなっていく運用になっています。
おわりに
以上ざっくりHiTTOのバックエンドで使われている技術の紹介でした。 常に改善していこうというスタンスなので、新しいものを取り入れたり既存のリファクタリングをしたりして、いいプロダクトが作れたらいいなと思っています！
ちなみにフロントエンドの技術はこちらです。興味があればぜひご覧ください〜。
というわけでHiTTOを一緒に作っていく仲間を募集しています！（宣伝🌟）
