フロントエンドでGraphQLを使った所感

1

自己紹介

名前

　李 超（ 31）

経歴

中国上海出身。 2008年来日、 2015年 11月サイバーエージェントに入社。

職種

フルスタック修行中のフロントエンジニア。

広告関連システムの管理画面や SDKの開発を担当している。2

目次

・ GraphQLを導入した理由

・実際使った時の問題

・現時点の改善案

・一フロントエンジニアとしての感想

3

GraphQLを導入した理由

・柔軟性

スキーマさえ定義すれば好きな組み合わせで取れる。

・可読性

JSONっぽい構文なので、直感的でわかりやすい。

・技術的なチャレンジ

何より新しい技術であること。

4

・フロント

AngularJS 　 1.5.X

・サーバ

Scala 　 　＋ Sangria

5

実際使った時の問題点

・クエリ変換時に罠が多い

・ jsファイルがとにかく重い

・コンソールでデバッグしづらい

・サーバ側で処理の重さが把握しづらい

6

クエリ変換時の罠が多い

const　str　=　‘abcde’;　　=>　`strParam:　”${str}”`

const　arr　=　[1,　2,　3];　=>　`arrParam:　[${arr}]`

const　enum　=　{　RED:　0,　GREEN:　1　}; 　 ではなく

const　enum　=　{　RED:　‘RED’,　GREEN:　‘GREEN’　}; 　 じゃないと

　‘求められているのは enumParam:　RED’

‘enumParam:　0’は決して許されない

const　obj　=　{　a:　1,　b:　2　};　=>　`${JSON.stringify(obj)}` 　 orz...

String

Array

Enum

Object7

jsファイルがとにかく重い

　短い方 =>

　長い方 =>

8

似ているクエリは山ほどある！

すべては jsファイルに入っている！

それは重いよね。。。

更にクエリを最適化すると、バリエーションも増えるので、

もちろん更に重くなる。。。

9

コンソールでデバッグしづらい

こちらはとある編集画面のリクエスト一覧

すべてが gqlへの postなので、どれが何をするためのクエリはわからない＞＜

途中でさすがに我慢できなくなり、 _getLoginUserみたいな query　stringを目印としてつけたけど。。。

10

うん。。。やっぱりわからん。。。

これは人が読めるものではない。。。

中身を見てみると

11

サーバ側で処理の重さが把握しづらい

ちょっと極端な例をあげると

まず、下記のような関係があると

class　has　many　students　

student　belongs　to　class

もちろん、親から子、子から親は取れるようにスキーマを定義した

とすると。。。12

class　{　students　}　 　が投げられる =>　想定内だと

class　{　students　[{　class　}]　}　 　も投げられる =>　まあ、大丈夫だろ

classes　[{　students　[{　class　}]　}]　 　も投げられる =>　あれ？ちょっと。。。

　実際はフロントで上記のように好きな組み合わせで投げられる =>　(@_@);;

「やはりフロントは処理の重さを理解した上で投げましょ」

という属人的なものが出てきてしまう13

現時点の改善案（フロント）

・クエリに variablesを利用とセグメント化

・ nodejsの中間サーバを用意し、 GraphQLをすべて中間サーバに移動

・クライアントとサーバのやり取りを RESTに戻す

　14

15

・ソース記述量が増えるが、クエリ文字列への変換は variablesの型宣言により、小細工をしなくて済む

・マスターデータは使う時基本同じ形にしているのでセグメント化をし、メンテナンス性がよくなる

・使う場面によってほしいカラムが変わるものはセグメント化しない。

16

client nodejs resourceserver

request

mergedresponse

merged　request　1

merged　request　2

response1

response2

GraphQLを nodejsに移動し、 RESTに戻す

17

現時点の改善案（サーバ）

色々試してくれたそうだけど、結果 GraphQLをやめることになった

18

一フロントエンジニアとしての感想

・ GraphQLでフロントが幸せになったことはない

・ GraphQLには向き不向きがある

向き :　インスタやタイムラインなどクエリのバリエーションが少ないもの

不向き :　広告関連の管理画面などテーブル構造が複雑で、クエリのバリエーションが多いもの

・ GraphQLの誕生によって RESTが消えることはないと思う

19

ご清聴ありがとうございました！

20