えっと...ポリポリ...
単に面倒だからかな...
開発スピード遅くなるよ。みたいな。
いや、まあ、お使いの方にケチをつけたいわけじゃないですよ。
フロント側に期待する結果を送るためにいろいろサーバー側で準備しておくより、フロント側が相談したらすぐにサーバー側(API側)で、対応してくれた方がらくというかなんというか、
あと、TypeScriptの型とちょっと相性が悪いというかいろいろ苦しいような気がしました。ケースバイケースで、よりよい解決策があるのかもしれませんが、見つけられず、ひどい型の合算を経験したりとかですかね...
GraphQL Apoloから返される自動生成される型がぐにゃぐにゃしまくっているので、読み取るのが非常に大変かつ型パズルを解かなきゃならなくなる羽目になり結局解けなくて妥協の産物になってしまったりしたりしなかったり。
GraphQL使わずに、サーバー側が丁寧にRESTAPIを送ってくれて、フロントが要望したら、すぐにサーバーのRESTを直してくれる、みたいな連携がチームとして取れるプロジェクトなら、別にGraphQLのメリットはないかなと。
そんな気がしてます。
学習コストも相当あるので、ま、まあ、どうかな。
自分がプロジェクトの神のような存在でなんでも決められる立場だったりしたら...私は採用しないかな、みたいな。
あ、でも、GraphQL使っているプロジェクトは難易度高そ
… (もっと読む)
結論から言うと、組織の問題です。
日本でGraphQLを採用しているのは例えばYahoo!とかメルカリとかです。
両方ともバックエンドが既にマイクロサービスで構築されていて、BFFとしてGraphQLを採用しています。REST APIだけでクライアント側でなんとかするのが辛いパターンですね。
一方で、GraphQLは次のような点を導入時に考えておく必要があります。特にN+1問題とクエリのコストは重大です。
そしてスタートアップでフロントエンドエンジニアとバックエンドエンジニアが同じチームなら、REST APIでもさほど困りません。そこまでコミュニケーションコストが高くないので。
まとめるとこんな感じです。
- マイクロサービスをまとめるためのBFFとしては非常に有効
- GraphQL特有の問題がある(N+1、クエリのコスト)
- フロント、バックが同じチームならREST APIで十分
例えばTechnology RadarでもまだAssess(評価段階)です。
冒頭に書いたYahoo!やメルカリのような、バックエンドを集約するパターンはTrial(やる価値あり)になってます。
しかしそもそもマイクロサービスを採用している企業が日本では少なく、一部のメガベンチャーに限られているようなんですよね。
だからGraphQLを採用を採用するモチベーションがない、これが直接の原因です。
なので、GraphQLを普及するためには、マイクロサービスを普及させる必要があります。もちろん最初からマイクロサービスを導入するのはアンチパターンですが、エンジニアを数十人くらい抱える企業ならできててもおかしくないと思います。
なぜなら、1チームの適正人数は6±3人程度で、エンジニアが数十人いる時点で複数チームに分かれている必要があり、複数チームがモノリシックでやっていくのは困難だからです。
こうして問題は「中程度の企業がマイクロサービスを採用できないのはなぜか」に帰着されますが、これはエンジニアの問題よりも、組織の問題が大きいと思います。
その理由がこの動画で述べられています。
ところがですね、メリット以外に、反対に悪いこともあります。非同期化するとどうしても不整合が起きるんですね。
これ僕の友達が実際にFacebookで書いてましたけど、商品がお届け完了になっているのに商品が手元にない、こういう不整合がでるわけですね。
このときにAmazonはどうするかというと、300円のクーポンをくれます。
これは非常に大事なことです。
サービス間を疎結合にするためには不整合を受け入れます。
受け入れたものはどうしますか。運用でカバーしましょうというのが、Amazonですらそうなんですね。
技術で解決してないですよね。疎結合化を受け入れるということはこういうことです。
今までやっていた、クオリティ、品質、整合性を保つための考え方を変えない限り、分割はできない。
データ分離もそうですし、メッセージ連携も同じですが、非同期化するということは不整合を受け入れるということです。
これがどうしてもダメなのであれば、マイクロサービスを諦めてください。できないです。
マイクロサービス化するためには不整合を受け入れる(結果整合性)必要があり、そのためには「運用でカバー」する必要があります。すると、エンジニアだけではどうしようもありません。運用やビジネスを含めた、組織を巻き込む必要があります。
しかしその結果として「今後の成長のためにチームを分割して機動的にする必要がある。だからマイクロサービスにしよう」と言える組織はほとんどありません。そしてだんだん鈍重になり、成長が止まっていきます。だから組織の問題なんですよね。
まあ、マイクロサービスはあくまで手段で、モノリスのままで保守性を高める方法もあります。ですが、ほとんどの組織はそれ以前に、技術的負債が溜まっていて、マイクロサービスどころじゃないと思いますが。
0 コメント:
コメントを投稿