GraphQLやめました | GiFT（ギフト）株式会社

GraphQLやめました2020.05.27 当初Golang + GraphQLで作っていたAPIをRails + OpenAPIで作り直しました。なぜGraphQLで始めたのか、どうして作り直すことにしたのかなどを経緯とともにまとめました。 始まり弊社では qrop という農家さん向けのサービスを鋭意開発しています。 私はAPI等のバックエンドの開発を主に担当しており、このサービスの開発を始める段階でAPIは GraphQL にしよう、という話になりました。 GraphQL | A query language for your APIこの時点でGraphQLである必要性はなく、詳しいメンバーがいたわけでもなく、新しい技術に触れておきたいよねという程度の理由でした。 せっかくだしGolangで開発しよう、インフラはGCPにしよう、という具合にその時やりたいことを詰め込んで開発はスタート

[a2ikm]

GraphQL それ自体の問題というより、開発体制に起因するもののようだった。

[hisaju]

技術選定はメンバーの特性から判断しようといういい教訓。Railsは良くも悪くも一定の水準に揃えやすい。

[gabill]

新しい事は同時に複数やらない方が良いね。

[gfx]

慣れない技術スタックは無理があったという話。RailsでGraphQLにするって手もあったと思うけど。

[Wafer]

何一つ具体的なことが書いてない。プロジェクトの立ち上がりから終了まで全部ふわっふわ

[munyaX]

知らない技術は小さいプロジェクトで試してからが鉄則だよね。見積もりの精度も落ちるし。

[sathoeku]

“理想を追うこと自体は悪いことではないと思いますが、そこにこだわりすぎても身動きがとれなくなってしまうこともあるように感じました。”

[khtno73]

技術的な制約、要件との相性みたいな話ではなく慣れや学習コストと要員の現状スキルの問題なのかな。よくわからんがボカさなきゃならんとこもあるだろう。

[raydive]

すでに稼働してるものを移行した話かと思ったら、作り上げることができなかったという話だった。けどコスト考えるとそうなるよなぁという納得感ある。

[dorokei]

チャレンジするのはいいことですよね。

[knjname]

分かる　もちろんGoやGraphQLのせいではないんだろうけど、技術者の生産性って根底の知識や経験もあるけど、慣れの部分がかなり大きい　慣れないのものをいくつも詰め込むと死ぬ

[yamadadadada2]

採用と継続運用開発のトータルのコスパでRailsが一番やりやすいっちゅうのはありそう。次点がlaravel、Nest.jsあたり？

[threeMonths]

「開発に何が求められているか」

[takezaki]

“仮にシンプルな機能で完結していたとすればGraphQLでやりきれていたと思います。 しかし当初の（私の）想定よりシステムに求められる機能が複雑でありそれを実現することがだんだん難しくなっていったと感じて”

[RYoMa_0923]

新しい技術スタック全部盛りしちゃうとしんどいよね〜

[zentarou]

「慣れない技術使うのやめました」ってだけか

[kura709]

#Rails #OpenAPI