2020年、iopool は、自社のアーキテクチャが開発速度を遅くし、イノベーションを妨げていることに気づきました。そこで、Lambda 関数と Prisma を利用したリレーショナルデータベースに切り替えることにしました。これにより、彼らが自信を持って迅速に行動し、開発プロセスを大幅に簡素化できた方法について、以下をお読みください。
暑い夏の日に、美しい青いプールに飛び込んで涼むのは最高です。また、飛び込みたいのに、プールが藻で覆われた緑色で、水泳にはまったく適していないのを見るほど最悪なことはありません。さらに面倒なのは、手動テストの必要性、PH レベルの修正方法の理解、追加する化学物質の量の調整などです。
そこでiopoolが登場します。彼らは、洗練されたプールセンサーとモバイルアプリから始まり、プールを清潔で安全に保つために必要なすべての製品を含む、プライベートプール、ジャグジー、ホットタブ向けの完全なプール管理ソリューションを提供しています。
技術的負債
2020年、iopool のエンジニアは、会社の技術スタックの将来を危険にさらす深刻な技術的負債の問題に直面していることに気づきました。iopool のリードソフトウェアエンジニアである Luc Matagne 氏は、これらの技術的な課題の深刻さを認識していました。彼の言葉を借りれば、「開発者にとって悪夢」でした。
プロジェクトには 16 のマイクロサービスがありました。ファイル構造、コード構造、ツールには多くの違いがありました。すべてのデータは、「偽の関係」を持つ NoSQL データベースに保存されていました。さらに問題だったのは、すべてのサービスを自分のマシンでローカルに実行できなかったことです。各サービスをテストするには、クラウドにデプロイする必要がありました。
このアーキテクチャが iopool の将来の成長にとって問題になることを知っていた Luc 氏は、iopool のバックエンドの新バージョンに向けて、包括的な変更を提案しました。それには、個々のマイクロサービスのリッピングアウト、リレーショナルデータベースへの切り替え、そしてその中心となる Prisma の実装が含まれていました。
Prisma への道のり
Luc 氏は、iopool のバージョン 1 を失敗とは見ていませんでした。むしろ、それは LIT (学習、反復、テスト) アプローチへの彼らのコミットメントを示しており、これを学習と捉え、アプリのデザイン、バックエンド、コードをゼロからリファクタリングすることを可能にしました。
多くの開発チームは「リファクタリング」と聞くと身をすくめるでしょう。必要な時間と労力を考えると当然ですが、iopool には追加の障害がありました。それは、2 年かかった製品を 6 か月足らずでリファクタリングする必要があったことです。彼らはまた、6 月に始まる次のハイシーズンに間に合わせる必要もありました。
iopool には ORM を選択する際に 5 つの要件がありました。
-
スピード → 学習曲線はほとんどなく、可能な限り迅速に実装できる必要があります。1 週間で、データベースが実行され、すべてのデータへのタイプセーフアクセスが可能になりました。Prisma Schemaを使用してデータベースを構築することで、最初から最適なデータベースを得るために、さまざまな構造を迅速に反復処理することができました。「Prisma がなければ、iopool 2.0 を時間どおりに準備することは決してできなかったでしょう。」
-
柔軟性 → 彼らは競争力を維持するために多くの新機能をリリースする必要がありました。Prisma と Nexus の組み合わせにより、リゾルバーの管理が容易になりました。すべてが常に簡単にアクセスできました。
-
使いやすさ → データの行き先 (または行かない場所) を理解するために必要なマイクロサービス間の複雑なパスを削除しました。Prisma は、必要な方法でデータを簡単に取得するのに非常に役立ちました。
-
信頼性 → 開発の最初の 2 年間で彼らが逃したことの 1 つは、ユニットテストでした。彼らはついにバックエンドの各プロセスにユニットテストを追加することができました。Prisma Client をテストプロセスに組み込むことは非常に簡単で、コードベースをはるかに信頼性の高いものにしました。「Prisma を使用すると、コミットごとに安心して眠ることができます。マージンエラーは非常に小さくなります。」
-
快適さ & 生産性→ 彼らはローカルサーバーを使用して機能をライブテストできるようになり、それは Prisma ですぐに利用できました。それは彼らにとって非常に大きな生産性の向上でした。
新しい技術スタック
要件を特定した iopool は、真新しい技術スタックを使用してバックエンドのバージョン 2 の作業に取り掛かりました。
新しいスタックは、React Native、GraphQL (Apollo を使用)、Postgres、DynamoDB などの一般的なテクノロジーに依存しています。バージョン 2 では、Prisma が重要な役割を果たしています。
大幅にアップグレードされた iopool のバージョン 2 では、AWS Lambda を介してサーバーレス関数が広範囲に使用されています。Nexus は、React Native アプリから呼び出される GraphQL API を提供するために使用されます。Prisma Client は、iopool が水質データ以外すべてに使用する Postgres データベースにアクセスするために使用されます。収集された膨大な量の水質データについては、DynamoDB がこの種のデータを大規模に簡単に処理できるため選択されました。
バージョン 2 で TypeScript、特に Prisma と Nexus を使用するようになったことは、大きな成果を上げました。以前のマイクロサービスアーキテクチャでは 2 ～ 3 週間ごとに 1 回リリースしていましたが、iopool は現在、週に 2 回以上リリースできるようになりました。以前は数週間かかっていた機能開発が数日に短縮されました。
Prisma を見つけたので、プロジェクト全体のリファクタリングを開始することにしました。特にリファクタリングを行う時間が限られていたため、Prisma が私たちをより速く、より自信を持って進めるのに役立つと確信していました。
開発サイクルが改善されたのは、主に Prisma が提供するタイプ安全性によるものです。Prisma Clientを使用してデータベースアクセス呼び出しを行うときに、iopool の開発者がインテリセンス、オートコンプリート、およびタイプチェックを利用できるようになったことは、速度向上に不可欠でした。
Prisma Migrateは、iopool のバージョン 2 アップグレードでも重要な役割を果たしました。Migrate は、データベーススキーマの変更に対するアプローチにチームに自信を与え、複数の開発者が中央スキーマで共同作業を行い、変更を環境全体にシームレスに適用できるようにしました。
スキーマを編集または変更するとき、Prisma を使用していれば、動作すると確信しています。
結論
iopool は、Prisma が中心にあったおかげで、バックエンドのバージョン 2 の開発をスムーズに進めることができました。Prisma により、開発者はより迅速に行動し、バージョン 1 では達成が困難だったであろう新機能を実装し、会社の将来に新たな可能性をもたらすことができました。
iopool が Prisma でどのように成功したか、そして Prisma 自体についてさらに詳しく知るには、以下のリソースをご覧ください。
次回の投稿をお見逃しなく！
Prisma ニュースレターにサインアップしてください