Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
検索のMicroservices化 with Apollo Server
Search
roolrool
December 07, 2018
Technology
1.7k
2
Share
検索のMicroservices化 with Apollo Server
roolrool
December 07, 2018
More Decks by roolrool
See All by roolrool
本番環境のRailsプロダクトでGraphQL API / GraphQL API on Rails Products in Production
roolrool
1
1.7k
Other Decks in Technology
See All in Technology
数案件を同時に進行するためのコンテキスト整理術
sutetotanuki
2
230
プロダクトを触って語って理解する、チーム横断バグバッシュのすすめ / 20260411 Naoki Takahashi
shift_evolve
PRO
1
280
DevOpsDays2026 Tokyo Cross-border practices to connect "safety" and "DX" in healthcare
hokkai7go
0
140
最近の技術系の話題で気になったもの色々(IoT系以外も) / IoTLT 花見予定会(たぶんBBQ) @都立潮風公園バーベキュー広場
you
PRO
0
110
聞き手の目線で考えるプロポーザル
takefumiyoshii
0
380
こんなアーキテクチャ図はいやだ / Anti-pattern in AWS Architecture Diagrams
naospon
1
290
昔はシンプルだった_AmazonS3
kawaji_scratch
0
220
終盤で崩壊させないAI駆動開発
j5ik2o
2
1.9k
ある製造業の会社全体のAI化に1エンジニアが挑んだ話
kitami
2
950
2026年、知っておくべき最新 サーバレスTips10選/serverless-10-tips
slsops
12
4.3k
DevOpsDays Tokyo 2026 軽量な仕様書と新たなDORA AI ケイパビリティで実現する、動くソフトウェアを中心とした開発ライフサイクル / DevOpsDays Tokyo 2026
n11sh1
0
120
Sansan Engineering Unit 紹介資料
sansan33
PRO
1
4.2k
Featured
See All Featured
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
199
73k
Why Our Code Smells
bkeepers
PRO
340
58k
Kristin Tynski - Automating Marketing Tasks With AI
techseoconnect
PRO
0
220
Building Adaptive Systems
keathley
44
3k
VelocityConf: Rendering Performance Case Studies
addyosmani
333
25k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.6k
Building the Perfect Custom Keyboard
takai
2
720
エンジニアに許された特別な時間の終わり
watany
106
240k
AI in Enterprises - Java and Open Source to the Rescue
ivargrimstad
0
1.2k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.4k
Data-driven link building: lessons from a $708K investment (BrightonSEO talk)
szymonslowik
1
1k
The Spectacular Lies of Maps
axbom
PRO
1
690
Transcript
スペース検索のMicroservices化 with Apollo Server 2018.12.6 Ryosuke Yamamoto
2 自己紹介 Ryosuke Yamamoto ( @roolrool ) よちよちWebバックエンドエンジニアです。 男子シンクロのインストラクター、 Webディレクターを経て2017
年1月にスペースマーケットにジョイン。 直近では新規事業やリニューアル PJを担当。 開発比率:Webバックエンド 9:1 Webフロント
3 改めまして、
4 先日サイトリニューアルしました!
5 before after トップ
6 before after スペース検索一覧
7 ではバックエンドは何がどう変わったのというお話。
8 アジェンダ • リニューアル概要 • 検索用DBの作成 • GraphQL APIの実装 ◦
Apollo Server ◦ knex.js ◦ TypeScript • まとめ
9 スペース検索のMicroservices化
10 リニューアル概要
11 旧全体図 スマートフォンアプリ REST/GraphQL Webフロント/サーバー クライアント API DB RDS for
MySQL
12 リニューアル後全体図 スマートフォンアプリ REST/GraphQL Webフロント/サーバー クライアント API DB RDS for
MySQL GraphQL Amazon Aurora
13 何をしたか • 検索用のキャッシュテーブルをRDS for MySQLからAmazon Auroraへ移行 • REST APIからGraphQL
APIへ移行 • Ruby on RailsからNode/Express/Apollo Serverへ移行 ポイント
14 検索用DBの作成
15 検索用DBの作成 • 検索結果に必要なデータだけを持つテーブルを作成 ◦ スペース、空き情報、お気に入りなど • 新規検索機能に答えられる設計 ◦ 正確な空き時間検索など
• 発行クエリ数やjoinを最小限に抑えられる設計 • スケーラブルなシステム ◦ Amazon Auroraを採用 ▪ AutoScale・Reader Endpointによる読み込みの負荷分散 方針
16 GraphQL API
17 GraphQL API • GraphQL Server:Apollo Server • HTTP Server:Express
• クエリビルダー:knex.js • 言語:TypeScript 技術スタック
18 Apollo Server
19 Apollo Server • Apollo Client ◦ React.jsやVue.jsなどのframeworkで使用するGraphQL Client ◦
弊社の各クライアントサイドでも使用 • Apollo Server ◦ ExpressにアドオンするGraphQL Server ◦ 今回初使用 • Apollo Engine ◦ Apollo Serverのモニタリング、パフォーマンス計測 ApolloプロジェクトのOSS
20 Apollo Server • ユニバーサルJSの流れ • 公式ドキュメントが充実 • APIドキュメントを自動生成 ◦
GraphiQL的なもの • playgroundが便利 • Apollo Clientとの親和性が高い ◦ バッチリクエストなど • Apollo Engineでモニタリングが容易 Why Apollo Server Why
21 Apollo Server - playground -
22 Apollo Engine
23 Apollo Server 少し解説 #server.ts
24 Apollo Server • Object TypeやEnum Typeなどのスキーマ定義 • 記述方式は通常のGraphQL schema
language • 今回のリニューアルでは参照のみ( Mutationなし) スキーマ定義
25 Apollo Server スキーマ定義(実装) • typeごとに分けてmerge
26 Apollo Server • 各プロパティごとにresolver内で解決した値を返す • スキーマ定義に記述した型で返す resolver
27 Apollo Server resolver(実装) • resolvers/index.tsを server.tsでimport • 処理が多いresolverは メソッドに切り出し
28 Apollo Server • 第三引数以降にオプションを設定可能 ◦ contextの受け渡し ◦ Apollo Engineの設定
◦ playgroundの有効化 Apollo Serverの初期化
29 Apollo Serverの初期化(実装) Apollo Server • 各resolversで使用するものは contextで受け渡し ◦ ログインユーザー
◦ DBコネクション • playgroundはdevelopmentのみ
30 Apollo Server • ExpressのミドルウェアにApollo Serverを追加 ◦ defaultでは`/graphql`にルーティングが作成される • listenするportを指定
Expressとの連携
31 Apollo Server • ユーザー認証のタイミング ◦ リクエスト時にtokenが渡った場合はRDSに問い合わせ、有効ならユーザー情報を ひく ▪ Apollo
Serverをnewする際のcontext引数にユーザー情報を渡す ▪ 今考えると当然、でもその時はちょっと悩んだ思い出 • ディレクトリ設計/ファイル分割単位 ◦ resolver内は重くなりがちな印象 ▪ 各schema定義、各resolver、各modelは分けた方がよさそう ▪ 情報が少ないので、あるべきは自分たちで考えないといけない 実装時の個人的お悩みポイント
32 knex.js
33 knex.js knex.jsとは • JavaScriptベースのSQLクエリビルダー ◦ resolver内でのDBアクセス時に使用 • メソッドチェーンで直感的にSQLを組むことができる •
インターフェースとしてはコールバックや Promiseなど • トランザクション処理もサポート • コネクションプーリング • Rails同様のmigration機能 ◦ 今回は使用せず
34 knex.js (例)
35 knex.js (例) _人人人人人人人人人人_ > わかりやすい!!<  ̄Y^Y^Y^Y^Y^Y^Y^Y ̄
36 knex.js 〜 O/Rマッパーに甘やかされた人間が救われた図 〜
37 TypeScript
38 TypeScript 使ってみて • JSのスーパーセットなので導入しやすい • VSCodeの補完が便利(interfaceの定義など) • Flowと違って型定義が必須なのがよい(必殺 anyという手も)
39 まとめ
40 • JavaScriptともっと仲良くなりたい
None