GraphQLサーバを作る苦しみと解決手法

E2Eテストから負荷試験シナリオを作ってみた / Why do we make a scenario of load testing from E2E testing scenarios

[jiro68]

GraphQL を採用したいのはバックエンドの事を何も考えずに済むフロントエンドの人間だけのように思う。特にデータモデルが込み入っているケースだとパフォーマンス要件を満たせる気がしないので GraphQL は採用しないな。

[dot]

GraphQLやってみて感じるのは、RESTではサーバやDBの都合でI/Fが決まったが、GraphQLではフロントエンドの都合でI/Fが決まる感じ。設計の重心がサーバからReactやVueなどのフロントエンドにシフトしている印象。

[khtokage]

インピーダンスミスマッチ解消の苦労をどこに押し付けるか、かな？

[h3poteto]

こういうのを待ってた！みんなGraphQL褒めるし使いやすいのはわかるけど，サーバ側の実装について誰も触れてないし，ヤバそうなんだよね

[Keisuke69]

GraphQLが嬉しいのは主にフロントエンド側の人。あと少しずれるが自分で作らずともAppSyncみたいなサービスとか有りモノ使うのでもいいかと

[shag]

ビジネスとしてこれを採用するアドバンテージってなんだろうな。backend 側が managed な *aaS になってしまえばすごく便利な気はするけど、そこまで行ったら既に競争価値としては薄いってことだろうし。

[kazuph1986]

"最先端のモダンPerl" だった。

[sh19910711]

"GraphQLに対する抵抗感は何だったのかが少しわかった / たぶん今までのサーバの作り方を制限する仕様"

[diveintounlimit]

トップコメントの認識がまさに思っていたとおりのことだったので安心した

[KoshianX]

バックエンドも型の使える言語でやらないとあんまりメリット受けられないのかな……

[otchy210]

GraphQL が RDB とすこぶる相性が悪いのはよく分かる。NoSQL だと、設計にもよるが、大分違うだろうと思う。

[new3]

やっぱ近寄らんどこ…

[ko-ya-ma]

用途が絞られるけれど、ドキュメント型DBとTypeScriptの組み合わせだとわりと作りやすいかと。BFFみたいのを立てて、RDBでRESTfulなバックエンドを併用するなんてのもあり

[miyasakura]

GraphQLは単純なREST APIよりもフロント側の複雑度を下げられる。しかしサーバー側も意識しなきゃいけないので当然フロントチームに求められる能力は上がる。こうやってサーバー側が頑張るも良いけど限界あるよね

[Caesarion]

パールが悪いじゃん

[ducktoon]

欲しいパラメータをクライアント側で決めないといけないのが辛い (えっ？)

[kabochatori]

SQL文をそのままリクエストしたいって気になってくる

[sugimomoto]

本筋と関係無いけど、気になってしまった・・・！　OpenAPI はWeb向けクエリ言語じゃなく、APIの定義を記述するための仕様。

[onesplat]

再度選択した理由に手戻りが多いけど、じゃあ最初からGraphQL採用しなけりゃよかったんじゃね？あの技術は理想論によるオナニー感が強いので俺は未来永劫BETしないわ

[t-cyrill]

わかる。しかしPerl