@ku KUMAGAI / newmo, Inc. 2024-08-24
 GraphQLとスキーマファーストで切 り開く
 ライドシェアの未来

@ku KUMAGAI 自己紹介
 ku 断続的にiOSをやってきました 2008-2010 iView(プライベート) 2010-2014 GREE 2017-2021 メルカリ(メルペイ部分) 直近はgolangでバックエンドをやっていま す ku

弊社紹介
 ● 2024年1月4日設立の新しい会社 ● タクシーとライドシェア事業を通じて “移動で地域をカラフルに ” をミッションにしています ライドシェア タクシー

ライドシェアとタクシーの違い
 ● ライドシェア (自家用車活用事業) ○ 一種免許(普通の運転免許)のドライバー ○ 自家用車 ○ タクシー会社と雇用契約 ● タクシー (一般乗用旅客自動車運送事業者) ○ 二種免許を持つドライバー ○ 会社の車 ○ タクシー会社の正社員(が多い) ● 両者ともタクシー会社が安全管理を行います ■ 車両の点検 ■ 健康状態の確認(飲酒、睡眠不足、etc)

ライドシェアとは
 タクシー事業に関する法律 道路運送法78条 自家用自動車は、次に掲げる場合を除き、有償で運 送の用に供してはならない。
 1. 緊急災害時
 2. 非営利団体の活動
 3. 公共の福祉のため
 タクシーの不足分を補う自家用車活用事業

4月からはじまっています
 曜日と時間帯で定義された、タクシーが不足してい るときに限定されています。東京の場合は 月-木 7am-10am 金 7am-10am 4pm-7pm 土 0am- 4am 4pm-7pm 日 10am-1pm 雨が降るときも不足が予想されるので、利用可能時 間帯に追加されました

技術的観点での差分
 ● デバイス ○ タクシー ■ 会社の車両、メーター、スマホ/タブレット端末 ○ ライドシェア ■ 携帯端末はドライバーのものを使ってもらう ● アプリの仕様 ○ 例) 決済 ■ タクシーは現金OK あと払い ■ ライドシェアはオンラインで事前決済のみ

サービスに必要なモバイルアプリ群
 ● ドライバー向け 似ているけどひとつにするのが難しい ○ タクシー ○ ライドシェア ● 乗客向け

アプリ構成
 ● iOS 17~ ● TCA (the Composable Architecture) ● apollo-ios (GraphQL client) ● Swift Concurrency

クロスプラットフォーム技術の検討
 ● サードパーティSDKのサポート状況 ● 物理的なサービスなので端末の持つセンサーを様々な形で利 用したい ● プラットフォームごとの知識はやっぱり必要(ビルド環境、ストア の提出フロー構築) それぞれのプラットフォームでベストな体験を作りたいのでネイティ ブという結論に

GraphQLの利点
 1. 各アプリが必要なものだけ取得できる ● 各アプリチームが自律的に最適なAPIを使える 2. ディレクティブによるスキーマの拡張性 ● 実装ではなくスキーマに振る舞いを記述できる 3. Apollo Federation ● BFF(Backend For Frontend)の開発スケーラビリ ティを確保できる ● 各チームの自律性

GraphQL directive
 フィールド等にメタデータを付与できる input UpdateProfileInput { name: String! email: String! birthDay: String! @deprecated( reason:“use birthDate”) birthDate: String! }

生成されるSwiftコード
 Apolloのコードジェネレータがavailable attributeを生成 します struct UpdateProfile: … { public var name: String public var email: String @available(*,deprecated,message:”use birthDate”) public var birthDay: String public var birthDate: String }

カスタムディレクティブの利用
 ● 標準のディレクティブ以外に自分で定義できる ● 機械可読な形式で一元的に管理できる ● pluginでディレクティブを含んだASTから任意のコードを生 成可能 ○ 入力値のチェック ○ APIスタブの生成 ○ 権限の管理 ○ etc.

利用例1 入力値のバリデーション
 input UpdateProfileInput { name: String! @validateString(minLen: 1, maxLen: 64) email: String! @validateString(pattern: EMAIL) } ● 有効な値の範囲を示すディレクティブ ● extensionとしてvalidate()メソッドを生成して入 力値をアプリ側で検証 ● validate()が返すエラーをもとにメッセージを表示

生成するSwiftコード
 extension GeneratedGraphQLPackage.CreateRideInput { func validate() -> CreateRideValidationError? { guard (name.count >= 1 && name.count <= 64) else { return .init(field: .name, message: ”...”) } guard try emailRegex.wholeMatch(in: email) != nil else { return .init(field: .email, message: ”...”) } return nil } }

apollo-ios-cliだとできないけれど...
 apollo-ios-cliはコード生成プラグイン的なサポートはなくカスタ ムdirectiveを活用できません🥲 かわりにgraphql-codegenのpluginとして実装しています(ロ ジックはTypeScriptで記述)

newmo🧡OSS
 React用は公開しています

利用例2 APIスタブの生成
 type NumberPlate { place: String! @exampleString(value: "品川") classificationNumber: String! @exampleString(value: "300") hiragana: String! @exampleString(value: "れ") serialNumber: String! @exampleString(value: "2525") } ● 値の具体例を示すディレクティブ ● 生成したスタブの返す値を明示

利用例3 権限の管理
 type Query { carsNearMe(): [Cars!]! } type Mutation { requestCar(input:…): RequestCarPayload! @requiresMembership } ● 認証が必要かどうかを表すディレクティブ ● スキーマを見れば認証が必要なAPIがわかる ● アプリ側で認証が必要か判断できて、とりあえずリクエストして レスポンスから必要しなくてよくなる

利用例4 ログのマスキング
 type Customer { id: ID! homeAddress: String! @PII(level: STRICTLY_CONFIDENTIAL) bankAccount: String! @PII(level: TOP_SECRET) usageCount: Int! } ● 個人情報かどうかを表すdirective ● 個人情報を行動ログにそのまま送ってしまいがち ● スキーマで定義しておけば機械的にマスクできる

まとめ
 ● GraphQLのディレクティブを使ってより宣言的な開発が可能 です ● (今日は触れられなかったけど)GraphQLには開発するときの チームの自律性を高めてくれる仕組みがあります ● newmoはGraphQLでネイティブで たくさん アプリを作っていきます

● たこやきのフードトラック近くにブースがあるので遊びに来てく ださい ○ newmo iOS Design Blueprint ポスターで技術トーク! ○ 地図とか車とか好きな方 ● ニューモタオルや塩タブレットがもらえます(数量限定) ありがとうございました


● カジュアル面談やっています ● ビアバッシュというカジュアルな会もやっ ているので、じっくり聞きたい方はぜひ声 をかけてください