モバイルアプリ＆GraphQL化と壁を超えたコラボレーションを実現するために できそうな観点を探る

Omotesando.rb #96の登壇資料になります。

私が現在、モバイルアプリ開発を中心としながらも、業務内でバックエンドでのコードを見る様にしてみた際に変わったことの中で、下記3点に焦点を当ててご紹介しています。

1. RESTful APIからGraphQLへ置換する際においてできる事
2. Backend処理＆Mobile処理間における「つなぎ目」の意識がある事で役立つケース紹介
3. 実際に僕がRailsコードを見る際にはどの様な事を考えているか？

個別知識の集まりが繋がった時に理解が深まる様な点を見つけるポイントの解説が中心になります。

※過去の勉強会でもお話ししたトピックも含まれていますが、モバイルアプリのBackend開発時におけるアイデアや参考になれば幸いです。

Transcript

1. モバイルアプリ＆GraphQL化と 壁を超えたコラボレーションを実現するために できそうな観点を探る Omotesando.rb #98 2024/06/06 Fumiya Sakai
2. 自己紹介 ・Fumiya Sakai ・Mobile Application Engineer アカウント: ・Twitter: https://twitter.com/fumiyasac ・Facebook: https://www.facebook.com/fumiya.sakai.37 ・Github: https://github.com/fumiyasac ・Qiita: https://qiita.com/fumiyasac@github 発表者: ・Born on September 21, 1984 これまでの歩み: Web Designer 2008 ~ 2010 Web Engineer 2012 ~ 2016 App Engineer 2017 ~ Now iOS / Android / sometimes Flutter
3. iOSのUI実装本を執筆しています！ 書籍に掲載したサンプルのバージョンアップや続編等に現在着手中です。 少しの工夫で実現できるTIPS集やライブラリ表現の活用集をはじめとした、iOSア プリ開発の中でも特にUI実装やUIKitを利用した画面の中で特徴を与える様な表現 という題材に焦点を当てた書籍となっております。 現在は電子書籍版のみとなります。 こちらは全て¥1,000となっております。 https://just1factory.booth.pm/ 概要: https://book-tech.com/ 価格: 📖 Booth 📖 Book Tech
4. UI実装であると嬉しいレシピブックの最新情報 UI実装であると嬉しいレシピブックVol.3として昨年10月に商業化しました！ Still WIP これまでの同人誌として頒布したものに加えて、Vol.1及びVol.2に頒布したものの 中で書籍に載せきれなかったものや表現や動きが特徴的でユーザーにもほんの少し 遊び心を与える様なUI実装を紹介したものをVol.3としています。 概要: これからの構想: こちらで購入可能です: Amazon / Google Play / Apple Books / KINOKUNIYA / Rakuten BOOKS etc.. 🏊 iOS: SwiftUIを利用したUI実装や動画関連の実装 🏊 Android: Jetpack Composeの基本やその他気になるUI表現の考察
5. モバイルアプリエンジニア時々バックエンドを見る 業務内でバックエンドでのコードを見る様にしてみた際に変わったこと 普段はiOS/Androidアプリケーション開発が中心ですが、いわゆるバックエンドを見る際に考えている事の紹介です。 1. RESTful APIからGraphQLへ置換する際においてできる事： 実際に想定しているレスポンスの認識をお互いに合わせるためのコミュニケーション＆コードレビュー。この様なステップを挟 む事によって、実装者と利用者間における懸案事項の解消や想定するユースケースを合わせやすくなると思います。 2. Backend処理＆Mobile処理間における「つなぎ目」の意識がある事で役立つケース紹介： 複雑な機能を実現するための実装に向き合う際には、クライアントでどの様にデータが利用され、どの様な役割を担っているか に目を向ける必要があると感じています。その際に両方の事情を知っておくと良さそうな例を紹介します。 3. 実際に僕がRailsコードを見る際にはどの様な事を考えているか？： Railsのバージョンが4〜5系だった当時に実務経験はあるがブランクが空いている状態でした。プロダクションコードを読み進め ながらキャッチアップや調査をする際に「自分なり」に考えている事を紹介できればと思います。
6. GraphQLを良さを最大限活用するためにできそうな事 Schema定義に注目する事がCommunication＆Collaborationを生み出すきっかけ 認識を合わせる際に実装前に歩調を合わせ、その後にSchema定義を元に議論する様なイメージが理想形 Request 📲 Response Mobile App Ruby on Rails Apollo GraphQL Mobile処理はApolloを活用 実装前にどの様なデータを返すかの議論 実装者＆PO間で議論 Backend Engineer Mobile Engineer Product Owner 1. download schema definition 2. set xxx.graphql file 3. generate codes 嬉しい点 1. Query/Mutationの形を元に議論が可能である点 2. 画面構築イメージとも照らし合わせやすい点
7. GraphQL関連のキャッチアップを自分でも実施する Mobileアプリ関連の勉強会でも注目があるトピックなので気に掛ける様にする 登壇資料： https://speakerdeck.com/ymanya/swiftdemoapollo-iosdekuai-shi-nigraphql Swiftでもapollo-iosで快適にGraphQL https://speakerdeck.com/chocoyama/swiftuitographqltehurotakutofalseji- sok-de-napo-huai-nili-tixiang-kau SwiftUIとGraphQL でプ ロ ダ クトの継続的な破壊に立ち向かう 解説ブログ： https://zenn.dev/saboyutaka/articles/e5515872871534 GraphQLはいつ使うか、RESTとの比較 https://zenn.dev/saboyutaka/articles/07f1351a6b0049 GraphQLが解決する問題とその先のユースケース HAPPY ＋ = ❤ https://x.com/fumiyasac/status/1677948595872612353 Tsukiji.graphql #1 への参加記録ノート
8. GraphQLに関する調査に役立ったツールの紹介 平素の開発や仕様調査の際に便利なツールを積極的な活用ができると良さそう 現在は自分がGraphQLの開発よりも調査・現場把握する事を重視しています。 1. Proxyman: 2. graphql-voyager: https://proxyman.io/ https://github.com/graphql-kit/graphql-voyager Debugging Proxy Tool GraphQL Schema Relationships
9. 大規模なものを調査する際にはDB関連の知見も役立つ 以前にゲームのバックエンド開発経験で得た知識も結構役立った点でした 大量のRequest/ResponseをMySQLで捌く必要がある例： https://speakerdeck.com/ymanya/swiftdemoapollo-iosdekuai-shi-nigraphql 秒間100万クエリを受け付ける大規模ソーシャルゲームのバックエンドDBシステムの設計・運用ノウハウ https://speakerdeck.com/takihito/sosiyarugemugagao-fu-he-nixian-tuteirutoki-he-gaqi-kotuteirufalseka ソーシャルゲームが高負荷に陥っているとき、何が起こっているのか 事例に触れてみる メタデータロックに関する例： https://yoku0825.blogspot.com/2020/08/mysql-80-vs-vs-alter-table.html MySQL 8.0 vs 外部キー制約 vs ALTER TABLEでメタデータロック待ちになったら疑うこと https://gihyo.jp/article/2023/11/mysql-rcn0208 MySQLのALTER TABLEステートメント実行時の注意点 大規模なものに機能開発や施策を積極的に入れる際に注意
10. Backend処理＆Mobile処理間における「つなぎ目」の意識 技術要件を満たすと同時に関係するセクションとの円滑なやり取りのため 📱 Mobile App Mobileアプリに限らず昨今の高機能化や深くプロダクトに携わる中で必要な知識や知見は増えていく。 開発する上で「つなぎ目」となる部分の知識や知見の大切さを感じるタイミングはあるはず。 ビジネスサイドからの 要望の実現可否 アプリ利用ユーザーからのお問い 合わせの原因調査 Web / Android 等の他deviceと比べ た時の違いの見極め デザインとの兼ね合いや Animation / Interaction バックエンド側で提供している API通信処理との連携対応 内部アーキテクチャや継続的なデ リバリー環境の整備 高機能化・複雑化 機能開発・改善・保守
11. Mobileでのログイン処理とBackend処理との関係図解例 ログイン処理とログイン後のJWTを利用した認証トークンの扱いの復習 成功 or 失敗時のレスポンス 📱 新規User作成 DB登録処理 OK: Client (Mobile App) Server (API Local Server) Userログイン NG: エラー処理 ログイン後の コンテンツ表示 [POST] /api/v1/signup: username・mailaddress・passwordを送信 [POST] /api/v1/signin: mailaddress・passwordを送信 成功 or 失敗時のレスポンス JWTを発行 OK: NG: エラー処理 [GET] /api/v1/items?page=1 成功 or 失敗時のレスポンス HeaderのJWTを検証 リクエスト時のHeaderに保存したJWTを付与してRequest（有効期限は1日） ・有効期限切れ ・存在しない → ログイン画面へ戻す Keychain等でアプリ 内にJWTを保持
12. AWSを利用したPush通知基盤例 Amazon SNS & AWS Lambdaを利用した場合のPush基盤設計の例です ※この部分はAppDelegate.swiftで実施 (UNUserNotificationCenterDelegate) 初回起動時 ①Push通知で送る内容を 組み立ててLambdaを実行 ②SNSの処理を実行して APNsへPush通知を送信 📱 APNs 送信処理実行 Push通知を受信する 後は内容に応じた処理を実施 アプリ起動時における処理の流れ プッシュ通知許可 この時に表示されるリモートプッシュ通知の 許可ダイアログはFCMに対して実行するもの。 補足: ③ デバイストークンをサーバーへ登録する ※①〜③は起動時に毎回実施される処理 Server DBにUserのに紐づく DeviceTokenを保持 しておく。 ② デバイストークンを受け取る ① registerRemoteNotification() 実行 Mobile App
13. デザインにおけるWebとアプリの違いを見極める例 Webであれば頻出ではあるがアプリだとちょっと一手間がかかる事例 Mobileはやや難 文章内にテキストリ ンクが存在する＆画 像表示エリアもある 様な形を実現する。 意外にWebでは頻出だけどもMobileではあまり見ないもの 補足: パンくずリストの様な形のUIはあまりお目にかからない… Railsでの実装アイデア リッチエディタの様な形が難しい場合はMarkdown記法を利用する 記事等のリンクや画像URL付きコンテンツに関し てはMarkdown形式のままで保存＆を表示する。 Redcarpet: https://github.com/vmg/redcarpet Mobileで内容を表示する Markdown形式の文書を表示できる様に実装する。
14. Railsの仕様調査をする際の読み進める順番について 手掛かりを見つける際には該当部分のUnitTestから辿る場合も多い 🤔 時間に余力がある場合にはノートやドキュメントへまとめる様にしておく ①まずはEndpointを特定する 今回の処理対象となっている部分を 特定するための第一歩。 起因となったErrorメッセージやロ グデータ等があればヒントにする。 モバイル・バックエンド・インフラ 等の切り分けができているか？ ②該当処理部分にUnitTestはあるか 該当処理と思われる部分にUnitTest は記載されているか？ UnitTestから元々の仕様が把握でき る様な形になっているか？ ③実装箇所の詳細を調査する DB定義等も合わせて該当処理の概要 を自分の言葉でまとめてみる。 限られた時間の中で関連性を探るた めに便利なツール等を活用する。
15. (余談) Quick/NimbleはRSpecにインスパイアされている 実は下記機能はiOSのQuick/Nimbleでも搭載されています 僕がRailsコードを調査する際にまずRSpecに注目するのは、書き方が似ている点をヒントにすると読みやすかったから。 1. shared_examples： itの部分ないしはcontext〜itの部分を共通化して名前をつけて管理する。 2. it_behaves_like： shared_examplesで共通化したテストコードを呼び出す。該当呼び出したいshared_examplesにつけた名前を付与する。 RSpec.shared_examples 'start_wonderful_event' do it '何かすごいイベントが始まる' do # expect ... で期待する結果を記載する end end describe 'Wonderful Event' do let(:event) { create(:event) } # 個別にitを書くのではなく定義したshared_examplesを呼び出す it_behaves_like 'start_wonderful_event' end
16. まとめ 最初は個別知識の集まりだが繋がると理解が深まる 個人的にもバックエンド開発等に領域を広げる事で発見も多い実感があります！ 1. GraphQLの活用によって仕事がしやすくなった実感がある： Schema定義やQuery/Mutationの形ありきでの議論ができるので、コミュニケーション・コラボレーションの機会が増えた様に思 います。今後はドキュメンテーション等の課題も生まれそうだが、メリットを十分に感じる事ができています。 2. つなぎ目の意識を持つ事で個々の知識が繋がる： 今回紹介した点は直接的にRubyやRailsの実装とは直接的な関係性は薄いですが、この様に背景にある技術やとりまく環境に関す る知識が少しでもあると、理解を進めていく際に役立つ場面もあると思います。 3. 調査する事や自分の言葉でまとめる事を恐れない： 最初は「わからない事がわからない」状態になるのは致し方ないと思います。最初は「自分の言葉で表現しながら整理する」と ころから始め、便利なツールも適宜利用しながら楽しく＆効率よく進める様にしていって頂けると嬉しいです。
17. Thank you for listening !