enechain の技術スタック ~2023 夏~

はじめに

こんにちは。enechain で CTO を務めている @sutochin26 です。

今回は enechain の最新技術スタックを紹介したいと思います。過去にも技術スタックについては note 記事にて紹介しておりましたが、当時からいくつかのチャレンジを経て注力技術も変わってきました。今回は、技術選定における考慮事項とともに、改めて最新情報をまとめて紹介いたします。

ざっくり結論から言うと以下のような技術に注力しておりますが、今回は Web Fronetnd / Backend を中心に最新の技術スタックについて紹介させて頂きます。

Web Frontend

React

enechain の各プロダクトの Web Frontend は基本的に React で記述されています。 Vue で動いているプロダクトが 2 つありましたが、一方は React への移行が完了し、もう一方もここから 1 年以内を目安に移行予定です。（Vue で書いたコードはフリーズ状態で、追加の開発はほぼ行なっていません。）

React 採用のタイミングでは、Vue で実装したコンポーネントがある程度充実しており、Vue を使い続けるという選択肢もありました。しかし、コミュニティの活発さやエコシステムの充実度合い、サービスとのマッチ度合い、採用上の強さなどを鑑みて React の採用に踏み切りました。

ライブラリ郡

React と合わせて利用されているライブラリ郡も社内である程度統一されており、Component Library には Chakra、複雑なユースケースの状態管理には Recoil、データ通信には TanStack Query を利用しています。その他、Storybook、Zod、React Hook Form、Recharts も積極的に利用しています。

コンポーネント郡は、デザインシステムをベースとして各プロダクトでビジュアルを共通化しています。最近では lint や prettier 等の rule も全社共通化しており、フロントエンドについては統一感が高まってきました。

デザインシステム整備やルールの統一化はフロントエンドエンジニア達の有志の元に始まっており、こういった熱量が生まれたことを考えても React の採用は良い選択だったと感じます。

Backend

バックエンドについては Go, gRPC, Connect の利用が社内で主流になりつつあります。

Go

創業からしばらくは、エンジニア採用の問題もあり Node.js（Express/NestJS）を利用していました。少人数のスタートアップにとって TypeScript でフロントからバックまで書ききれるメリットは大きく、多くのスタートアップで採用される技術スタックかと思います。

一方で、システムが複雑化・肥大化していくに伴い、サービスを適切に分割していく必要が生じ、Node.js の処理速度やデプロイの複雑さが課題になってきました。

Go の採用はこういった課題に対する 1 つのソリューションでした。「ライブラリ等に頼らず自前で書く」という思想が強い言語であり、ガバナンスやコード品質の観点で不安はありましたが、外部コードへの依存が弱い分メンテナンスコストも抑えられて、「増え続けるサービスを限られた人員で運用していく」という観点では良い思想だと感じています。

Go の実装方針（DI や ORM）についてはまだ社内でベストプラクティスがあるわけではなく、もう少し試行錯誤を繰り返した後に統一感を上げていければと考えています。

gRPC / Connect

サービスが分割されていき、サーバ to サーバの通信が増える中で、通信には gRPC の採用が増えています。

「gRPC サーバを Web フロントエンドから叩こうとするとプロキシが必要になってしまう」という点が悩ましかったですが、 Connect を利用することによりフロントエンドからも叩けるようになりました。これにより、「最初は Web フロントエンドから直接叩きたいが、いつかマイクロサービス化して BFF から叩く可能性がある API」を迷わず Connect で実装出来るようになりました。

既にフロントエンドとの通信が発生する部分では Connect を採用しており、Frontend は TanStack Query の拡張パックである Connect-Query を用いて実装しています。

NestJS / GraphQL

「GraphQL エンドポイントを BFF として設置し、その裏に Go/gRPC のマイクロサービスが並ぶ」という構成も検討しています。特に Fragment Colocation を用いたフロントエンドコードの可読性・メンテナンス性の向上に期待して GraphQL を選定していました。

まだ社内で GraphQL の利点を活かしきれていない感があり、 Connect の利用と並行してこちらも技術検証を進めていきたいと考えています。

Infrastructure

enechain のプロダクトは現状全て GKE 上で動いています。

創業初期の開発は App Engine や Cloud Functions を活用することで少人数で迅速な開発を実現していましたが、事業規模の拡大に伴いプロダクト間の連携も多くなり、アーキテクチャがどんどん複雑化していきました。ガバナンスが効きにくく、複雑な作業で時間を使ったりミスをすることも増えて、開発に集中出来ない状況になりつつありました。

このような課題に対応するために GKE を導入しました。急激に拡大する事業・チームに対し、横断的にガバナンスを効かせることが可能になり、セキュリティも強固に保つことが出来ます。

現在、GKE をエンジニア全員が自身で運用出来るよう、Tech 本部全体で学習中です。（SRE Desk のメンバーが学習コンテンツをたくさん作ってくれており、皆で楽しく学んでいます）

本記事内で詳細には触れませんが、後日記事化予定です。