Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
GraphQL Serverをつくる・つなぐ / GraphQL Server: constructing and bonding API
LINE Developers
PRO
December 18, 2019
Technology
2
3.2k
GraphQL Serverをつくる・つなぐ / GraphQL Server: constructing and bonding API
12/18に開催されたFROKAN × UIT #2 「年忘れLTバトル」での発表資料です
https://uit.connpass.com/event/152518/
LINE Developers
PRO
December 18, 2019
Tweet
Share
More Decks by LINE Developers
See All by LINE Developers
SIGMOD 2022 国際会議報告 / Report on the International Conference SIGMOD 2022
line_developers
PRO
0
52
テクニカルライティングの検定を受けてみた話 / "My Story About Taking the Technical Writing Exam
line_developers
PRO
1
220
ぼくらが選んだ次のMySQL 8.0 / MySQL80 Which We Choose
line_developers
PRO
7
3k
バッファープールが大きいMySQL v5.7でDROP DATABASEが詰まった原因と対策 / Causes and Remedies for DROP DATABASE Stuck in MySQL v5.7 with Large Buffer Pool
line_developers
PRO
4
830
LINEをdual stack環境に変更した話
line_developers
PRO
0
83
日本人が英語でやりがちな失敗 / Common mistakes in English that Japanese people tend to make
line_developers
PRO
4
520
”Change”our private cloud infrastructures from single-AZ to Multi-AZs
line_developers
PRO
0
100
"Change" our private cloud infrastructures from single-AZ to multi-AZs Backbone Network part
line_developers
PRO
1
60
How to Support Multi-AZs in NFV Services
line_developers
PRO
0
45
Other Decks in Technology
See All in Technology
20220731 如何跟隨開源技術保持你的職涯發展
pichuang
0
120
Dangerous attack paths: Modern Development Environment Security - Devices and CI/CD pipelines
rung
PRO
0
150
cobra は便利になっている
nwiizo
0
140
LINSTOR — это как Kubernetes, но для блочных устройств
flant
0
3.8k
hey BOOK
heyinc
26
290k
eBPFで実現するコンテナランタイムセキュリティ / Container Runtime Security with eBPF
tobachi
PRO
5
1.8k
PMMやプロダクト関係者と協働するために役割を整理した話 / 20220810_pdmtipslt
rakus_dev
0
120
EKS AnywhereとIAM Anywhereを組み合わせてみた
regmarmcem
0
390
第22回 MLOps 勉強会:みてねのMLOps事情
tonouchi510
1
1k
塩漬けにしているMySQL 8.0.xxをバージョンアップしたくなる、ここ数年でのMySQL 8.0の改善点 / MySQL Update 202208
yoshiakiyamasaki
1
730
サイバー攻撃を想定したクラウドネイティブセキュリティガイドラインとCNAPP及びSecurity Observabilityの未来
syoshie
1
1.4k
Learning to Solve Hard Minimal Problems
takmin
1
500
Featured
See All Featured
How to name files
jennybc
40
63k
Building an army of robots
kneath
299
40k
Why You Should Never Use an ORM
jnunemaker
PRO
47
7.7k
Stop Working from a Prison Cell
hatefulcrawdad
262
17k
Typedesign – Prime Four
hannesfritz
34
1.4k
A designer walks into a library…
pauljervisheath
196
16k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
39
13k
We Have a Design System, Now What?
morganepeng
35
3k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
236
1.1M
Fontdeck: Realign not Redesign
paulrobertlloyd
73
4.1k
Principles of Awesome APIs and How to Build Them.
keavy
113
15k
The Invisible Side of Design
smashingmag
290
48k
Transcript
GraphQL Serverをつくる・つなぐ 2019/12/18 FROKAN × UIT #2 @spring_raining
About Me • Tamada Akihiro • Twitter: spring_raining / GitHub:
spring-raining • フロントエンドエンジニア at LINE株式会社 UIT • 普段はLINE公式アカウントを担当 Follow me! >
Agenda • 新規社内サービス立ち上げとGraphQLに出会うまで • GraphQL Serverをつくる • GraphQL Serverをつなぐ
LINE Design System (LDS) • LINEファミリーアプリ横断で用いる次世代のデザインシステム • #linedevday でたくさん情報が出てます LINEのデザインシステム:一貫性を損なうことなくLINEのサービスの速度を上げる
https://linedevday.linecorp.com/jp/2019/sessions/A2-2 デザインシステムにおけるフロントエンド https://linedevday.linecorp.com/jp/2019/sessions/A2-3
https://linedevday.linecorp.com/jp/2019/sessions/A2-2
https://linedevday.linecorp.com/jp/2019/sessions/A2-2
アイコン管理ツール LAICON • LINE社内のアイコン資産を共有するFont Awesome的なやつ • LDSに合わせてトーンを統一したアイコンにリニューアル中
宣伝っぽい導入終了
現状の問題点 • LAICONのリリースにエンジニアが関与しなければならない • ValidなSVGかチェック • アイコンの命名 • アイコンフォントのビルド・デプロイ
LAICON CMS 作るぞ! • アイコンを登録・管理するための社内サービス • プランナー・デザイナー自身がアイコンを追加する • 追加されるアイコンのレビュー・承認作業を行うフォーラム •
サービス毎にアイコンフォントのサブセットを管理できるとなお良さそう
• データ取得/操作をクライアントサイドで制御する言語・実行環境 • GraqhQLサーバーにクエリを投げると、そのとおりのデータが返る GraphQLについて query { user(id: "123") {
id name } } { "data": { "user": { "id": “123", "name": “spring-raining" } } }
なぜGraphQLを使うのか • フロントエンド側にとって、REST APIにはないメリットがいっぱい • APIリクエスト数の削減 • 余分なレスポンスの削減 • 社内サービスではすでに採用事例もたくさん
• 普段業務でサーバサイドを触ることが無いので興味本位で
GraphQL Serverをつくる
• 別途APIサーバーなどのBackendを持つBFFの構造ではなく、DB接 続、Session管理、GraphQLエンドポイントが一体のシンプルな構成 LAICON Backend CLI CMS web page Backend
GraphQL API 社内認証基盤 Session (Redis) DB (MySQL)
DBと接続 • TypeORMを使い、DB (MySQL) と TypeScriptのclassとマッピング • DecoratorでColumn等を定義 • DB関連はTypeORMに全ておまかせ
@Entity('users') class User { @PrimaryColumn() id: string; @Column({ nullable: true }) name?: string; @OneToMany( type => Icon, icon => icon.user ) icons: Icon[]; } @Entity('icons') class Icon { @PrimaryColumn() id!: string; @ManyToOne( type => User, user => user.icons ) user: User; }
GraphQL SDLとTypeScriptの同期 • GraphQL SDL(APIで取得できるデータ構造の定義言語)と TypeScriptは互換性があり、(だいたい)相互変換できる GraphQL SDL TypeScript graphql-codegen
type-graphql
@Entity('users') class User { @PrimaryColumn() @Field() id: string; @Column({nullable: true})
@Field( type => String, {nullable: true} ) name?: string; @OneToMany( type => Icon, icon => icon.user ) @Field(type => [Icon]) icons: Icon[]; } Entityの定義 @Resolver(User) class UserResolver { @Query(() => User, {nullable: true}) async user( @Arg('id') id: string ): Promise<User | null> { // implement } @Mutation(() => User) async updateName( @Arg('id') id: string, @Arg('name') name: string ): Promise<User> { // implement } } Query/Mutationの定義 type Query { user(id: String!): User } type Mutation { updateName( id: String! string: String! ): User! } type User { id: String! name: String icons: [Icon!]! } できあがるSDL
フォーラム機能の実現は少し大変 ユーザーがアイコンを アップロードして申請 デザイナー・エンジニアが レビュー リテイク要求 LAICON アイコンを追加されると 自動でアイコンフォントを リリース
フォーラム機能の実現は少し大変 ユーザーがアイコンを アップロードして申請 デザイナー・エンジニアが レビュー リテイク要求 LAICON アイコンを追加されると 自動でアイコンフォントを リリース
このワークフロー どこかに見覚えはありませんか…?
Pull Request
GitHubのPull Requestと同じ! • 都合の良いことにGitHub API v4はGraphQLで提供されている • 社内のGitHub Enterprise APIをそのまま使ってしまえばいいので
は?? • GitHub上にあるコメント等の情報がそのまま利用できる
GraphQL Serverをつなぐ
Apollo Federation • Apollo Serverが用意する機能 • 複数のGraphQL APIをまとめあげ、APIの連合を作る • それぞれのSchemeのtypeを関連付けることができる
複数のGraphQL Schemeの関連付け • LAICONのユーザーとGitHubアカウントを相互に参照したい • GitHub v4 APIにはUserやBotを抽象化したActorという概念がある ので、Actorのアカウント名からユーザーのObject Typeを引けるよう
にする API Endpoint GitHub v4 API LAICON API
Federated schemaの作成 type User @key(fields: "name") { id: String! name:
String @external icons: [Icon!]! } extend type Actor { user: User @provides(fields: "name") } GitHub側のActor objectに @provides directiveを与える const schema = buildFederatedSchema({ typeDefs, resolvers: { ...resolvers, Actor: { user(parent, args, context, info) { return findUsersByGithubName(parent.login); }, }, }, }); Resolversに実際の取得処理を書く LAICON側のSDL
Apollo Gateway • 用意したApollo serverの立ち上がっ ているURLを指定 • Apollo Federationに対応していれ ば、勝手にQueryやMutationをマージ
してくれる const gateway = new ApolloGateway({ serviceList: [ { name: 'laicon', url: 'http://localhost:5001', }, { name: 'github', url: 'http://localhost:5002', }, ], });
None
まとめ • GitHub v4 APIの利用はいろいろ考えるべき点はあるが、すでにある GraphQL APIを拡張して利用するアイディアは便利 • 世の全てのAPIがGraphQLで提供されてほしい…