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スキーマを使用してデータベースを構築することで、異なる構造間を迅速に反復し、最初から最高のデータベースを構築することができました。「Prismaなしでは、iopool 2.0を期限までに準備することはできなかったでしょう。」
-
柔軟性 → 競争力を維持するために多くの新機能をリリースする必要がありました。PrismaとNexusの組み合わせにより、リゾルバーの管理が非常に簡単になりました。すべてが常に簡単にアクセスできました。
-
使いやすさ → データがどこに行く（または行かない）のかを理解するために必要だった、マイクロサービス間の複雑なパスを排除しました。Prismaは、必要なデータを簡単に取得するために非常に役立ちました。
-
信頼性 → 開発の最初の2年間で見落としていたのが単体テストでした。最終的に、バックエンドの各プロセスに単体テストを追加することができました。Prisma Clientをテストプロセスに組み込むのは非常に簡単で、コードベースの信頼性がはるかに向上しました。「Prismaを使えば、コミットのたびに安心して眠れます。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が提供する型安全性に大きく起因しています。iopoolの開発者がPrisma Clientを使用してデータベースアクセス呼び出しを行う際に、インテリセンス、オートコンプリート、型チェックを利用できることは、速度向上に不可欠でした。
Prisma Migrateも、iopoolのバージョン2アップグレードにおいて重要な役割を果たしました。Migrateは、データベーススキーマ変更へのアプローチにチームに自信を与え、複数の開発者が中央スキーマで共同作業を行い、変更を環境全体にシームレスに適用できるようにしました。
スキーマを編集したり変更したりする際、Prismaを使用していれば、それが機能するとわかっています。
結論
Prismaが中心にあったおかげで、iopoolはバックエンドのバージョン2をスムーズに開発することができました。Prismaは開発者がより速く動き、バージョン1では達成が難しかった新機能を実装することを可能にし、同社の将来に新たな可能性を開きました。
iopoolがPrismaで成功した方法について、またPrisma自体について詳しく知るには、以下のリソースをご覧ください。
次回の投稿をお見逃しなく！
Prismaニュースレターに登録