株式会社ウェリコで、お客さんのスマートフォンでメニューの閲覧・注文・決済ができるスマートレストランを作ったときに、gqlgenとRelay Modernを使ってGraphQLを採用した話

1. 株式会社ウェリコ
会社紹介

2. 自由なレストランで、自由な体験を
ITと金融 力で
めちゃめちゃイケてる
飲食店を作る

3. 全体 流れ
お客様 来店 着席 注文 食事 会計 退店
ホール
②QRコードを読み取る
①来店登録、QRコー
ドを発行してお客様に
わたす
③iPadでオーダーを確
認し、調理する
キッチン
④調理が完了したら、
通知を受取って配膳す
る
⑤カードで会計をする
⑥会計が完了したら、お
見送りをする

4. レストラン スマート化 可能性
ホールキッチン
✔ 空席確認
✔ 予約確認
✔ アレルギー、好み 把握
来店後来店時来店前
✔ 納品受け取り
✔ 仕込み
✔ おすすめメニュー 考案
✔ メニュー表 更新
✔ 予約確認・座席案内
✔ 商品説明・レコメンド
✔ 配膳・バッシング
✔ お会計
✔ 調理タイミング 管理
✔ レシピ 共有
✔ スキル 可視化
✔ 満足度 把握
✔ 在庫棚卸
✔ 発注
お客様
✔ 予約
✔ 席 指定
✔ 料理・ドリンク 注文
✔ 会計
✔ 二次会 検索
✔ レビュー投稿
✔ PL管理
✔ マーケティング
✔ 採用
飲食店 運営業務 多岐に渡っており、それぞれが複雑に絡み合っている
SaaS ベンダーになる で なく、プレイヤーとして業務改善を図る
✔ シフト管理
✔ 立地戦略
✔ 顧客管理
✔ 人材教育（キッチン、サービス）
✔ メニュー開発

5. 飲食店 楽しいよ
- ご んが美味しい
- まかない、社割あり
- メニュー 試食
3店舗でスタッフ100人
MAU3万
- 人・人・人
- ユーザーが自分 目 前でアプリを使っている
- 店舗スタッフ→ 30人が10時間/日 * 365日
- ユーザー→1セッション2時間 * 来店者数
- ITによる自動化 ⇔ エモさ
- リアル x IT フロンティア
- レガシーな領域な で、課題だらけ
- 巨大なマーケット（デリバリー、生産）
- IoT/画像認識/ハードウェア、全部できます、お がいします
- 圧倒的なデータ量

6. スマートレストランでGraphQL
を採用した話
@wawoon_jp

7. Netlify
技術構成 GCP
GAE
go112
Cloud
SQL
APIサーバー
GCS
画像アップロード
Imgix
Pusher
リアルタイムイ
ベント通知
注文アプリ
店舗アプリ
Firebase
Auth
認証/認可
画像配信
GitHub
Push
ビルド/配信
通信（Relay Modern）
GraphQL

8. Netlify
技術構成（実際） GCP
GAE
go112
Cloud
SQL
APIサーバー
StackDriver
監視
GCS
画像アップロード
Imgix
Sentry
エラー通知
Pusher
イベント通知
注文アプリ
店舗アプリ
Firebase
Auth
認証/認可
画像配信
GitHub CircleCI
Push
自動テスト
ビルド/配信
Segment
イベント収集 BigQuery
ログ収集/分析
通信（Relay Modern）
+あといくつか SaaS

9. Why GraphQL
- やってみないとわからない（不確実性へ 対処）
- 特にフロントエンド
- とにかく実地でPDCA
- フロントエンド 何度でも作りなおす
- GraphQLなら、どんな画面やクエリ 仕方にも対応できる
- システムが落ちたらレストラン 営業がとまる
- API通信にも型がほしい
- GraphQLなら、型がある
- サーバーとフロント 型が合わないなら、ビルドでコケる

10. GraphQL採用してよかったこと
- リリース前: 開発スピード そんなに落ちない
- REST APIサーバー作るとき 時間 x 1.5くらいしかかからない
- 遅い？でもメリット たくさん
- スキーマ駆動開発しよう（ golang, gqlgen, sqlboilerいいぞ）
- サーバー用意できないとき モックサーバーを立てる
- GraphQL 型ファイルから自動的に作成
- リリース後: ほとんど 変更 フロントエンドで対応
- 新機能 ときだけサーバーサイドに変更
- フロントエンド 欲しいデータだけ、欲しい形式で取得

11. 大変だったこと
- API 設計
- REST APIとぜんぜん違う→GitHub APIを真似る
- パフォーマンス対策
- GraphQL クエリが巨大→クライアント側を直す、ロギング
- DBアクセス、N+1クエリ問題→SQLをバッチ化
- 並行処理でDBアクセス→コネクションプーリング事前に確保
- 実装むずい
- Relayでコネクションというリスト取得 仕様がある
- 振る舞い 仕様 あるけど、実装 決まってない
- → 自作テンプレートでORMをラップしたモデルから自動生成（ go generate）
- ロギング
- とにかく分散トレーシングだ！ → StackDriver Tracingいれた。簡単。

12. We are hiring
- 正社員、業務委託で エンジニアを募集しています
- 技術的に たぶん面白いことをやる ずです
- 過去 経験技術（使用言語など） 問わないです
- 小さなチームで大きな裁量をもって開発できる or チャレンジしたい人
- 年内にエンジニアを5人くらい採用したい
- Webフロントエンド
- サーバー
- インフラ
- IoT
- 興味がある人 、ブースで声をかけてください
- 自分（@wawoon_jp）、また 社長（@reI_araki）に@かDM

13. Appendix: 難しい点詳細 - サーバー編（１）
- N+1クエリ問題
- 事前にどんなクエリが来る かわからない
- eager loadingとかpreloadとかできない
- 発行されたも ベースで対応する必要がある
- SQLへ アクセスがあるときバッチ化する
- 2msなど、短い時間 sleep
- そ 間に同じクエリが発行されたらそれをバッチ化
- イメージ
- 0ms: goroutine1「select * from products where id = 1; 」発行したい
- 1ms後: goroutine2 「select * from products where id = 2; 」発行したい
- → まとめて、select * from products where id in (1, 2); で発行
- → 返り値をそれぞれ、goroutine1, goroutine2に返す
- ライブラリ
- https://github.com/vektah/dataloaden

14. Appendix: 難しい点詳細 - サーバー編（２）
- N+1を直してもDB刺さる問題
- GraphQL 1リクエストでも普通 HTTP通信 5-10個分くらい DB処理をする
- リゾルバがgoroutineで並行処理されているため
- DBコネクションがリゾルバ 並列数分使われる
- コネクションプーリング ボトルネックをどう直すか
- コネクションをApp Engine インスタンス 限界まで事前に用意（ 100コネクション）
- リクエストがたくさんきたら、インスタンス数を増やす
- 並行処理そもそもむずい
- sync.Mutex使うべし
- バグ事例
- DBアクセスしたデータを構造体 中にキャッシュ化
- 排他処理していなかった で、 goroutine 実行順によりランダムでレスポンスに失敗

15. Appendix: 難しい点詳細 - サーバー編（３）
- GraphQLリクエストがそもそもデカイと困る
- や いクエリ 例
- 100件ある商品
- 商品ごとに100件 オーダーを取得
- オーダーごとに、支払い 一覧
- 支払いしたユーザー ...etc
- 上記 場合だと、 100 x 100 x …. ような巨大クエリができあがる
- →今 制限かけてない でレビューで防ぐ
- Relay Specificationへ 対応
- offsetベースだと、新しいデータが入ってきたときに位置がずれる で以下から計算
- first, last: 何個ほしい か
- after, before: 基準となるノード ID
- go ジェネレーターでモデルから静的にコード生成して対応。

16. Appendix: 難しい点 - クライアント編
- とくに辛いこと ない
- Relay いいぞ
- GraphQLでつらい がキャッシュ管理だが Apolloより良くできている
- mutation周り, 特に削除処理
- mutation 直後など、ノードを消せ それで終わり
- query周り、データ 更新
- データ 再取得をするだけで、内部 キャッシュが更新
- 変更があったentityを参照している箇所、すべてで画面表示が更新される
- API ちょっとだけ難しい
- ドキュメントを読もう
- 特にコネクション キャッシュを変更するところが難しい