GraphQL：PayPal Checkoutのサクセスストーリー
この記事はPayPalのGraphQLの取り組みについての記事を翻訳したものです。随分前ですが天野もPayPal Japanで働いていました。
PayPalでは、最近GraphQLをテクノロジースタックに導入しました。
GraphQLのことを聞いたことがないのであれば、それは現在開発者の世界で話題になっているREST APIの代替手段です。
PayPalがGraphQLを導入することでデータについての考え方、データの取得方法、およびアプリケーションの構築方法が完全に変わりました。
このブログ記事では、PayPal Checkoutが、RESTからBulk REST、GraphQLに移っていく過程を経て学んだ事を紹介します。
これまでのAPIの軌跡
PayPalのCheckoutは多くのウェブアプリやモバイルアプリで使われており、200カ国以上の国々で何百万ものユーザーをサポートしています。常に何百もの実験が実行されています。アプリ内でUIの構築に必要なデータを取得するために一連のREST APIが用意されています。
REST
約4年前、私たちはRESTに全てを賭けました。私たちのAPIはとてもきれいで、小さく、そしてアトミックでした。当初は素晴らしかった。 RESTには、広く理解されている厳密な設計原則があり、 RESTはアプリのAPIを設計および実装するための優れた方法です。
ただし、RESTの原則は、Webおよびモバイルアプリとそのユーザーのニーズを考慮していません。これは、Checkoutのような最適化されたトランザクションに特に当てはまります。ユーザーはできるだけ早く自分のCheckoutを完了したいと考えています。アプリケーションがアトミックなREST APIを使用している場合、データを取得するためにクライアントからサーバーへの複数のリクエストが頻繁に発生します。 Checkoutを使用すると、サーバーでのリクエストの処理時間ではなく、1往復あたりのネットワーク時間が少なくとも700ミリ秒（99%の場合）かかることがわかりました。往復するたびにレンダリング時間が遅くなり、ユーザーのフラストレーションが増し、Checkoutのコンバージョンが低下します。言うまでもなく、往復は悪です。
もちろん、必要なすべてのデータを返すだけのAPIオーケストレーションを行うことはできますが、それにはトレードオフが伴います。何という名前ですか？ GET /landing-page？これはREST APIではなくJSON APIのようです。オーケストレーションAPIを使用すると、クライアントはサーバーに拘束されます。新しい機能や実験を追加するたびに、それをAPIを追加する必要があります。こんな事をしていると余計なデータまで取得してしまい、パフォーマンスは悪化し、そしてユーザーの体験は悪くなります。
新しい要件が発生したとき、開発者は選択に直面します。新しいエンドポイントを作成し、クライアントにそのデータに対する別の要求を出すべきか？それとも、より多くのデータで既存のエンドポイントにより多くのデータを追加するのか？
別のフィールドを追加してクライアントからサーバーへの往復を防ぐ方が簡単なので、開発者はしばしば2番目のオプションを選択します。時間が経つにつれてその場しのぎなこのアプローチはAPIを重くし、そして一つ以上の事を行うAPIが作られます。
最初の意図はいいものだったのです。一つのAPIでユーザー情報、配送先住所、資金調達オプションを返すものができました。 Checkoutアプリを構築するために必要なすべてのものが入っています。時間が経つにつれて、ユースケースは積み重なります。すべてのユーザーは、必要でなくてもこれらのフィールドのコストを負うことになるのです。
オーケストレーションAPIは最初は素晴らしいように見えますが、後でいつも後悔する羽目になります。
Bulk REST
RESTではうまくいかなかったので、この問題のいくつかを解決するBulk REST APIを構築しました。これは、クライアントが応答のサイズと形を決定することを可能にするその場で作られるのオーケストレーションAPIです。Bulk RESTを使用すると、アトミックREST要求を組み合わせて往復を減らすことができました。
注：これは、Batch REST（クライアント用の外部API製品）と混同しないようにしてください。これは、今年初めに紹介したBulk RESTの代替手段としてはるかに優れています。
これがBulk RESTのリクエストとレスポンスの例です。リクエストには、動詞、エンドポイント、パラメータ、およびそれらの間の依存関係を指定するREST操作が含まれています。
しかしこれはほとんど使われませんでした。
Bulk RESTでは、サーバーではなくクライアントがデータのサイズと形状を制御できるのがいい所でした。これによりクライアントの要件が変わるたびにオーケストレーションAPIを調整する必要がなくなりました。クライアントが基盤となるAPIがどのように機能しているのかを詳しく知っている必要があることが悪いポイントでした。リクエスト構造が複雑になり開発者が使わない理由になりました。また大きなリソースやオブジェクトではなく、特定のフィールドを取得できるようにしたいと考えていました。
Bulk RESTを提供している多くの企業（FacebookやGoogleなど）も同じ問題を抱えています。これは最適化されているが文書化されていない機能として扱われ、データを取得するための一番いい方法ではありません。
Bulk RESTは正しい方向への一歩でしたが、ゲームチェンジャーではありませんでした。
GraphQL
昨年、私たちのマネージャー（Brian Crescimanno）は私たちに2つの質問をしました。
「2018年にアプリを構築するための最高の方法は何ですか？」
「PayPalでアプリケーションを構築する方法をどのように改善できますか？」
パフォーマンスが問題であることは明らかでした。私たちは自分たちが望んでいたほど生産的ではないと感じていました。私たちは優れたUIエクスペリエンスを構築するのに十分な時間を費やしていないことを知っていました。
よく見てみると、UI開発者が実際にUIを構築する時間の1/3以下しか費やしていないことがわかりました。それ以外の時間は、データをどこでどのように取得するか、そのデータに対するフィルタリング/マッピング、および多くのAPI呼び出しの調整に費やされました。それに伴うビルド/デプロイの負担も乗っかります。それらの問題の解決の後、UIの構築を後付で行っていました。
その時、私たちはGraphQLについてよく話を聞くようになりました。私たちはGraphQLをよく見て一週間過ごしましたが、感動しました。幸いなことに、PayPal Checkoutをアプリに統合したい開発者向けのMobile SDKの新製品がリリースを控えていました。リリースまでに6週間、開発に3人の開発者がいました。
“ GraphQLを使ってみよう！” — 誰か
チームがUIを開発しているときに、APIを並行して開発していました。 APIの利用準備が整っていないにもかかわらず、PayPalに特有の知識をほとんど必要とせずに、機能やコードは予定より早く完成していました。開発者は、どの内部APIを呼び出すか、それを呼び出す方法、およびそのデータを使用可能なものに変換する方法を見つける必要はありませんでした。彼らはスキーマを調べるだけでできることを見つけ出し、GraphQLクエリー（ダブルクオート無しのJSON）を書き、そしてUIの開発を続けました。
私たちは何かすごい波にのっている事を感じました。開発の生産性があがり、アプリのパフォーマンスはあがり、ユーザーは幸せでした。 GraphQLに全てを賭けました。
開発者の経験とパフォーマンスに大きな問題がありました。 GraphQLはこれを解決し、それ以外の問題も解決しました。
パフォーマンス — 求めたデータだけを取得できます。これ以上でもそれ以下ではありません。１往復で全て事足ります。mutationの一部にクエリを追加する事もできます！
柔軟性 — クライアント側からデータのサイズと形を決めることができます。サーバー側ではなく。
開発者の生産性 — 特有の知識がなくてもすぐに生産性が向上します。 JSONを知っていれば、GraphQLを知っています。素晴らしいツールもたくさん！
進化 — GraphQLにより、API開発者はクライアントがどのフィールドを使用しているのかを正確に把握できるようになります。APIを退化または改良する際に、より良い選択をすることができます。 RESTではこれは不可能であるため、拡張したり削除はできません。
まだ始まったばかりです
Mobile SDKは始まりに過ぎませんでした。私たちは今、GraphQLとReactの上で主力のPayPal Checkout製品を改良しています。あなたがアメリカにいるならば、あなたは私たちの新しいスタックを使っている可能性が高いです。はるかに速くなります。 💨
GraphQLがさらにPayPalに大きな影響を及ぼしています。 1年後私たちは30以上のアプリ/チームがAPIを構築するかAPIを利用するようになる予定です。なにもかもいい話だけではありません。みなさんと共有したいくつかの間違いも犯しました。
PayPalでGraphQLに関する他の記事をチェックしてください！スキーマ設計のベストプラクティス、認証と承認、GraphQL APIのインスツルメンテーション（有効なログの追加）、本番用チェックリスト、実際のリモートスキーマステッチング、大規模組織へのGraphQLの展開についての考えを共有します。
私たちは採用しています！👋 フロントエンドのインフラストラクチャ、GraphQL、またはPayPalのReactで仕事をしたいという方は、Twitterの@mark_stuartまでお問い合わせください。