minneはなぜGraphQLを推進しているか

minneはなぜGraphQLを推進しているのか English Below
本プレゼンテーションでは、minneがGraphQLを採用し、Web、iOS、Androidなどのプラットフォーム全体でのユーザー体験向上を目指す取り組みを紹介しています。GraphQLを利用することで、API効率の向上、クライアントサイドのリクエスト負荷の削減、そして迅速な機能開発が実現されました。このアプローチは、価値を迅速に提供し、競合に先んじるというminneのミッションに沿っています。

主な内容:

マルチプラットフォーム体験を維持する上での課題。
RailsをBackend-for-Frontend（BFF）としてNext.jsと組み合わせる活用法。
RailsビューからNext.jsへの移行手順とGraphQL APIの利用方法。
GraphQLの利点（パフォーマンス向上、スキーマの再利用、チーム間のコミュニケーション効率化）について。

--
Why is minne Advocating for GraphQL?
This presentation highlights minne's transition to GraphQL and its adoption as a key technology for improving user experiences across platforms like web, iOS, and Android. By employing GraphQL, minne has enhanced API efficiency, reduced client-side request load, and facilitated faster feature development. This approach is aligned with minne's mission to deliver value quickly and outpace competitors.

Key topics include:

Challenges in maintaining seamless multi-platform experiences.
Utilizing Rails as a Backend-for-Frontend (BFF) with Next.js.
Steps to migrate views from Rails to Next.js using GraphQL APIs.
Benefits of GraphQL, including improved performance, reusable schemas, and streamlined team communication.

Transcript

1. 1 minneは なぜGraphQLを推進しているか kazu / GMO PEPABO inc. 2024.11.07 Omotesando.rb #103
2. 2 自己紹介 GMOペパボ　minne事業部　プロダクト開発チーム リーダー 2023年 中途入社 21卒 中山 一仁 Kazuhito Nakayama バックエンドが多い。けど、まあ全部やらせてくださいの 気持ち。 • あだ名 ： kazu • 好きな漫画 : 王様達のヴァイキング • X : @kazuhitonakayam • Github: kazuhitonakayama • Cosense(旧Scrapbox): kazuhitonakayama
3. もっとおもしろくできる 企業理念 ミッション 人類のアウトプットを増やす
5. 5 1. minne 紹介 minne（ミンネ）は、ハンドメイド作品を「買いたい人」と「売りたい人」をつなぐ国内最大のハンドメイドマー ケットです。パソコンやスマートフォンを使って、簡単にハンドメイド作品を販売・購入できます。
7. 7 本題
8. 8 この中でKaigi on Rails 2024 行かれた方いますか
9. 9 えらいGraphQLやな、と思われた方もいらっしゃるだろう @yana_gis 『カスタムしながら理解する GraphQL Connection』 @pyama86 『Tuning GraphQL on Rails』
10. 10 そうなんです
11. 11 なぜGraphQL推進が行われているか について話します
12. 12 アジェンダ 1. 問題意識 2. BFF(Backend for Frontend)としてのRails 3. こんな感じに進めてます ~具体的な施策を紹介しつつ~ 4. 終わりに
13. 13 アジェンダ 1. 問題意識 2. BFF(Backend For Frontend)としてのRails 3. こんな感じに進めてます ~具体的な施策を紹介しつつ~ 4. 終わりに
14. 14 - プロダクト開発の使命はより早く価値を提供していくこと - また、我々のプロダクトは競合に勝る機能を提供する必要がある プロダクト開発の前提として 問題意識
15. 15 - 今後もやはりweb、iOS、Android各プラットフォームのソフトウェアのメンテナ ンスが必要であることに変わりはない - アプリだけあれば良いかと言えば、購入者が検索流入するときに不便 - webだけあれば良いかといえば、モバイル端末のすべての機能を使える訳で はない。また、体験としてもアプリに優位がある - そこで、モバイルファースト・体験向上にあたり、 webについてどこまで Rails でやるか モバイルファースト、あるいはユーザー体験の向上が必要 問題意識
16. 16 - webにおいて、体験価値を向上させていくにあたって、JSによってインタラク ティブなUIを提供していく必要がある - もちろんRailsの上でJSをガシガシ書いたり - HotwireとかStimulus使ったり - react-railsやreact_on_railsなどのライブラリによって、Railsの上でReactを書 くなども選択肢としてある RailsとJSの程よい共存をいかに 問題意識
17. 17 - Railsの上のJSでリッチな表現を実現し続けていくことのいくつかの難しさ - デザイナーがUI実装をする際、幾らかのRailsの知識の必要性 - フロントのテストを記述していくにあたって、コンポーネント単位でのテストをする ことの難しさ - もしJSのコンパイルなどにおいて、リリースフローに問題が生じた時、ピュアな Rubyコードの差分のリリースに影響を及ぼし、ブロッキングになる可能性 RailsとJSの程よい共存をいかに 問題意識
18. 18 アジェンダ 1. 問題意識 2. BFF(Backend for Frontend)としてのRails 3. こんな感じに進めてます ~具体的な施策を紹介しつつ~ 4. 終わりに
19. 19 アジェンダ 1. 問題意識 2. BFF(Backend for Frontend)としてのRails 3. こんな感じに進めてます ~具体的な施策を紹介しつつ~ 4. 終わりに
20. 20 - そこで、RailsをBackend for Frontendとして、Next.jsでフロントエンドを 提供することで、ユーザー体験の向上の出発点とした - Next.js/iOS/Android ←→ Rails (BFF/GraphQL) ←→ Backend Services BFF(Backend For Frontend)としてのRails
21. 21 - 実はNext.jsをフロントエンドとして採用する少し以前より、GraphQLが導入さ れていたので、これを機にNext.jsからAPIリクエストする際は原則GraphQL にてやろうという流れに - なぜGraphQLか → 体験価値の向上 + より速い価値提供 - クライアントのリクエスト回数が減る + 無駄なデータの取得が減る という点でア プリの高速化 になる - クライアントが要求するリソースが変わっても、スキーマに定義されている範疇 においては、クライアントの変更だけで済む BFF(Backend For Frontend)としてのRails
22. 22 - Next.jsでのviewの提供によって、これまでよりリッチな体験を提供しつつ、 GraphQLを使った、より効率的なデータの取得によって、ユーザー体験を向上 させる - また、開発者体験としても、フロントエンドとバックエンドが疎結合になったことで 開発の複雑性を下げ、より速く価値のデリバリーができるように - viewだけの変更でビジネスロジックのCIを回さなくて良くなる - 型という基本要素を再利用することで開発の速度が上がる - フロントエンドのエンジニアにとってもRailsの知識が不要になって主戦場で開発 できる などなど BFF(Backend For Frontend)としてのRails
23. 23 アジェンダ 1. 問題意識 2. BFF(Backend For Frontend)としてのRails 3. こんな感じに進めてます ~具体的な施策を紹介しつつ~ 4. 終わりに
24. 24 アジェンダ 1. 問題意識 2. BFF(Backend For Frontend)としてのRails 3. こんな感じに進めてます ~具体的な施策を紹介しつつ~ 4. 終わりに
25. 25 とはいえ、もう2012年から始まったサービス。 10年以上の時を経ているのでRails viewの画面数が数百pある。 そのため、段階的にRailsのviewで作っている画面をNext.jsで作る画面に移行して いく。 こんな感じに進めてます ~具体的な施策を紹介しつつ~
26. 26 購入者と販売者がやり取りをするメッセージ画面にてテンプレートを使えるようにし よう！→画面に手を加えるなら、Next.jsでview書き換えよう こんな感じに進めてます ~具体的な施策を紹介しつつ~ Before After
27. 27 よって以下のようなステップでNext.jsによる画面へ移行 1. Railsのviewでの機能群の洗い出し→GraphQLの a. ピン留め、ピン外し機能 b. 画像アップロード機能 c. メッセージの取得 d. メッセージの送信 e. メッセージの既読化 2. Next.jsでの画面実装 こんな感じに進めてます ~具体的な施策を紹介しつつ~ およそ1ヶ月かかった、、、🔥
28. 28 GraphQLを推進して何が嬉しいか - 先述の通り、リクエスト回数および無駄なデータ取得がない分、負荷が減る - 型という基本要素を再利用できる - →推進していけば行くほど開発速度が基本的に上がるだろう - 実装してコマンド叩けばGraphQLスキーマが出来上がる - API仕様書の手動の更新が不要！！嬉しい using graphql-ruby - APIのスキーマについて、モバイルとのコミュニケーションが増えた - スキーマに変更があったらPRの段階でモバイルチームにもメンションされてPR 上で議論する こんな感じに進めてます ~具体的な施策を紹介しつつ~
29. 29 minneは なぜGraphQLを推進しているか kazu / GMO PEPABO inc. 2024.11.07 Omotesando.rb #103
30. 30 “ 全てはより早く、高い価値提供 をして事業を成長させるために ”
31. Thank You!! 31 みなさん、待ってます