GraphQLでバックエンドのコードをすっきりさせた話 - LayerX エンジニアブログ

こんにちは！LayerXの mosa_siru (榎本) です。 LayerX インボイスでは、もともと github.com/go-swagger/go-swagger を利用してREST APIを開発していましたが、最近開発したワークフロー機能 のコンポーネントではGraphQLを取り入れました。 GraphQLには様々なメリットがあり、RESTとの比較記事は多くありますが、なぜ僕らは移行したのか、その結果どうなったのかを紹介していきます。 GraphQLのメリット GraphQLのメリットは、様々な箇所で語られています。例えばこの記事によれば、 強力に型付けされたスキーマであること アンダーフェッチとオーバーフェッチがないこと（後述） Apollo, Relayなどの、クライアントライブラリにより、フロントエンド開発が迅速になること 複数のGraphQL APIからの統合が可能 強力

[holyshared]

この手のやつデータの整合性の話がでないのなんでだろ? Resolverが解決している間にデータが更新された場合、レスポンスがぶっ壊れたりする話を誰もしない 自分はそれを回避する為にDataLoaderを使用している

[amazedkoumei]

複雑さをどこにもってくかでしかない気がしてあんまり萌えないのよな GraphQL

[stakme]

ローダー実装が素直なら住心地よさそう（PKで引くだけとか）だけど、複雑な最適化やると意図せず変なクエリ投げてIO詰まって死んだりしそう。変なクエリ書くようなエンドポイントやめろと言われればそれはそう

[uhzz]

“ワークフロー機能”

[taisa831]

試してみよう

[Derabon]

帯域を抑えたいとか一定以上の複雑な場合には有効だけど、RESTの方が実装コスト低いから適材適所だと思ってる。

[ya6maDev]

GraphQLいつかは使ってみたいから、非常に参考になった！

[onesplat]

GraphQLは嫌いでもないんだけど、RESTやRPCでも十分シンプルに問題解決できるケース、むしろGraphQLのほうが面倒くさくなるケースもあるので、思い切った導入をためらうことが多いんだよな

[cpw]

コンポーネントが増えたり必要な知識が増える分複雑になるんじゃないのかな。後は大量に捌くとSQLでjoinするわけじゃないからパフォーマンスに悪影響になりそう。ちなみに使ったことはないし想像です。

[yogasa]

cord をすっきりさせるのかと思ったら……

[zgmf-x20a]

スキル不足で何がバレたのか分かってなかったりする…

[sigwyg]

GraphQLの話題はフロント側が多いので、バックエンドから「良い」という話が出てくるのは貴重かも

[rgfx]

なんか最近GraphQL推しきてるなあ

[kagehiens]

GraphQLって超楽観的なフェッチをしている気がするけど、使いどころを選べば良さそうではある。

[ryu39]

GraphQLのバックエンド側の最大の辛みがN+1の解消だと思っていて、それをよしなにやってくれるのであればめっちゃいい気がしてきた。

[iwtn]

今仕事で使っていて実感しているけど、ローダー使って遅延評価的な処理にするとGraphQLはかなり有望なバックエンドのAPIになる。N+1なしであの柔軟性はとても良い。

[jgoamakf]

伝わってる！気がする

[Nyoho]

「バックエンドコードの見通しの悪さの解決」

[mkusunok]

むっちゃ具体的な例で、これはメリットが分かりやすくていいね。Viewとの繋ぎのところでコード以上にDB呼び出しの無駄を減らせるのは超嬉しいな

[itotto]

RDBを使っていてGraphQLがいいっていう話はあまり聞かなかったので参考にする

[azihsoyn]

GraphQLがいいっていうエントリが増えるのはいいこと

[vvakame]

いい話