サービス開発を加速させる技術選定 in Kibela - Bit Journey's Tech Blog

2017/07/18 Service Dev Meetup #1 の資料です。 会場は Speee さんに提供していただきました。ありがとうございました。 自己紹介 FUJI Goro / @__gfx__ ビットジャーニーのエンジニア 最近のスコープ: Ruby on Rails / TypeScript / React / GraphQL 情報共有サービス Kibela を開発してます 最近の発表: RailsエンジニアがReactを始めてSSRとReduxとTypeScriptを導入するまで 今日の話 Kibelaにおける技術選定とは やらないこと やったこと これからやること Kibelaにおける技術選定とは 自分（@gfx）にとっては技術的挑戦は精神衛生上必要なこと 興味のある分野に限るが… スタートアップにとってはサービスの成長が最も重要 技術的挑戦によって機能を磨いて差別化に

[gfx]

#service_dev の資料です！

[teppeis]

どうも、質問した者です。

[kaakaa_hoe]

Limitについては、GitHubだとGraphQLで指定したnode(connection?)の合計数が500,000を超えると弾くみたいだ "By the time this query traverses to the comments connection, it is requesting up to 2,000,000 possible nodes which exceeds the maximum limit of 500,000."

[luccafort]

型付け頑張らないとか型定義こだわらないとかはちょっと意外だったが考えてみればそこに固執するのは本筋じゃないからいいのかーと納得出来て気持ちよかった。

[machupicchubeta]

"スタートアップにとってはサービスの成長が最も重要", "技術的挑戦によって機能を磨いて差別化にも繋げられればそれがベスト"

[plane25]

“総じてみると、GraphQLは「REST同様に問題が起きる可能性はあるが、RESTよりサーバーサイドで対応できる余地があるだけマシ」と言えるのではないかと思います” なるほどな

[june29]

「技術的挑戦は精神衛生上必要なこと」と言い切るのは気持ちのいいスタンスだと思いました。

[tenten0213]

“「 N+1が心配」⇢ RESTに置き換えて考える”

[masutaka26]

Kibela で GraphQL 導入するのか！ 細かいけど Elasticsearch が typo してる

[psfactory]

サービス開発を加速させる技術選定 in Kibela - Bit Journey's Tech Blog

[rjge]

“RESTが単位時間あたりのリクエスト数を制限するように、GraphQLの場合は、リクエストをパースしたあとの構造を解析してリソース取得のネスト数やリソースの参照数などをRate Limitのような形で制限する”

[myun2-nw]

“GraphQL”

[suthio]

“GraphQLは「REST同様に問題が起きる可能性はあるが、RESTよりサーバーサイドで対応できる余地があるだけマシ」”

[Surgo]

“技術的挑戦は精神衛生上必要なこと”

[el-condor]

勉強しておこう

[tofu-kun]

よい。GraphQLのN+1問題へのアプローチは確かにと思った。

[nagayama]

よいなー