クックパッドiOSアプリのトップ 画面を リニューアルした話 レシピ事業開発部 赤松 祐希

自己紹介 ● 赤松 祐希 @ukstudio ● レシピ事業開発部 サービスエンジニア リンググループ ● Webアプリケーションエンジニア ○ Ruby on Railsが主戦場 ● 最近ゲーミングPCを買って VALORANTというFPSをはじめました

iOSアプリのリニューアル

2月末にiOSアプリをリニューアル ● クックパッドではかなり大きいプロジェクト ● 2019年の春〜夏からプロジェクト始動 ○ 3段階に分けて順次リリース ○ 3段階目のリリースが2020年2月末 ● チーム規模は大体20〜30人ぐらい ○ (Slackのグループメンション調べ)

3タブ構成に ● アイデアタブ ○ 料理の楽しさをクックパッドから発信 する記事型コンテンツ ● さがすタブ ○ レシピ検索 ○ ハッシュタグ検索 ○ etc ● きろくタブ ○ レシピ投稿 ○ クリップ、レパートリー、料理きろく ○ etc

つくれぽリニューアル ● レシピ作者への感謝を送るものか ら、検索ユーザーへレシピをおす すめするものへ 出典: 13年続いた「つくれぽ」をリニューアルした話 https://note.com/misaaa09/n/nff84d4193447

毎日の料理を楽しみにする ● 人気順で時短・簡単な美味しいレシピを見つけることができるようになっ てきた ● でもクックパッドにあるレシピの中には他にももっと毎日の料理を楽しくし てくれるようなものがたくさんある ● そういった人気順では見つかりにくいレシピとの出会いや、楽しみをどう 繋げるかというところから、体験を捉え直して設計しなおしたのが今回の リニューアル

アイデアタブの実装

全体図 idea-backendと実際に呼んでないけど説明の都合上そう呼ぶ

全体図 ● ios-cookpad <-> Orcha <-> idea-backend 間はREST APIで通信 ○ 最近は内部的にgRPCを使うことが多いがここでは使っていない ○ 最初はOrchaを通さずにやり取りしていたため ■ 今ならgRPCを採用したと思う ● Orchaでは広告の差し込みとかが行なわれてる ○ 今日は話しません ● スタッフがMarkdownを入稿し、それをJSONに変換したものを idea-backendは返している ● Pantryと呼ばれるAPIから記事に表示するつくれぽやレシピの情報を取得

記事画面はネイティブ実装 ● Markdownを入稿する関係上、HTMLを 表示できた方が都合がいいため WebViewも検討はした ○ WebViewもハマりどころが多いた め、辞めた方がいいとアプリエンジニ ア交えて判断 ● そのため、MarkdownからHTMLではなく JSONを出力する仕組みを作る必要があ る ○ 右が実際のAPIレスポンスの例

各コンポーネントのJSONの構造を決める ● H1やH2のような見出しひとつとってもどういう構造のJSON にするか決める必要がある ○ アプリエンジニアとひたすら詰める ● インライン要素(太字とか)が結構厄介 ○ リリーススケジュールも有り今回は仕様からドロップ

MarkdownをJSONに変換 ● idea-backendはRailsアプリケーション(ただ しv4…)なのでMarkdownのパースにRuby製 のライブラリが使える ● 今回はKramdown( https://github.com/gettalong/kramdown )を採用 ● Kramdownには中間形式をHTML以外にも アウトプットする仕組みがあるのでそれを用 いてHashに変換

レシピやつくれぽを表示したいという要件 ● 当然そんな仕組みや記法はMarkdownにはない ● スタッフが「ここにレシピカードを表示する」というの をMarkdown上で指定できるなにかを考える必要が ある

独自記法の実装 ● 右記のような独自記法を実装す る ● レシピの例で言えばIDと表示形式 を指定 ○ 他にも様々なコンテンツ用の 記法があるが、基本的な仕組 みは同じ

Kramdownのdefine_parser ● Kramdownのdefine_parserを使うと「ある 正規表現にマッチした行は〜として扱う」的 なことができる ● {xxxx:xxxx〜 を独自タグとして扱う ○ convertメソッド内でマッチした文字列 に応じて適切な構造のHashに変換 ○ レシピIDからレシピ情報をPantryから 取得といったこともこのメソッドで

idea-backend、負荷試験で無事死亡 ● 今回大きいリニューアルということもあり、リリース100%公開前にSREの協 力のもと負荷試験が行なわれた ● その際にidea-backendが指定の負荷に耐えきれず死亡

Read-write splitting ● idea-backendは新規アプリではなく、元々あったクックパッドニュースのアプ リケーションに手を入れている ● DBはAuroraを使っており、ReaderとWriterも用意されてあったがアプリケー ションからはなぜか全部Writerを見ていた… ● 幸いアイデアタブからは読み込みのクエリしか呼ばれず、書き込みが必要 な入稿画面は別アプリとしてデプロイされている ○ 接続先のDBは環境変数で指定されているので、それぞれをReaderと Writerに指定することで解決 ○ 本来はRails6の複数DB機能などをちゃんと使う方がいいと思います

キャッシュの導入 ● 実は正確にはR/W splitting導入してたけど負荷試験に耐えられなかった ● リリースも近かったため、(渋々)キャッシュを導入 ● クックパッドによる記事コンテンツのため更新頻度は高くないのでキャッシュ のメリットは大きい ● キャッシュ自体はオーソドックスにRails.cache(memcached)で対応 ○ DBのアクセス、PantryへのAPIリクエスト、Markdownのパースなどま るっと省略できるようになった ● 無事負荷試験をクリア

まとめ ● iOSアプリのリニューアルの概要について話しました ○ まだまだ完成ではないので引き続き頑張っていきます! ● アイデアタブの実装について話しました ○ MarkdownをiOSでレンダリングしたい時の参考にどうぞ (あるのか?) ○ 負荷試験はやったほうがいいぞ!