本年一発目の登壇をしてきた話
タイトルには本年一発目の登壇ですが、このブログも本年一発目の更新でしたねw ことし始まって早くも1ヶ月が過ぎようというのに…！皆さんは進捗どうですか？←
登壇のテーマ
今回話したかった or 紹介したかった技術は主に2つ（厳密には3つ）。
登壇した際のスライド
実際に作ったスライドがこちら。
GraphQL はいわゆる BFF
スライドにも書きましたが、GraphQL も当たり前ですが銀の弾丸ではありません。すなわち、個人的な GraphQL の魅力は、いわゆる BFF (Back-end For Front-end 的な役割をしてくれるところにある点です。
現代では、どんどんマイクロサービス化が進んでいるように感じます。API も、責務を分けて保守性や拡張性を上げる動きがある一方で、それをコースするフロントエンドからすると、画面やビジネスロジック的には1つの画面なのに、叩く API ややり取りするサービスが複数個になるケースも増えてきています。
これによりサーバーとのアクセス（I/O）が増えるため、ネットワーク速度などパフォーマンスが低下する確率も上がりますし、エラーになる確率も上がります。また、データを取得できたとしても、その管理が難しく、フロントエンドで複数のサーバーから取得したデータをマージする処理が増えるため、バグが発生する可能性も上昇する、というデメリットも生じます。
それを、（ケース・バイ・ケースですが）フロントエンドでは1度のコールで複雑な構成のデータを取得できるようにしてくれるのが GraphQL の最大の魅力だと思います。（※とは言え、GraphQL も銀の弾丸ではないです。デメリットもいろいろ考えられるので、その辺は調べていただければ。）
今 GraphQL を使うならやっぱり AWS AppSync
GraphQL を扱う上でよく聞くフレームワークが Apollo というものがあります。簡単に渡しも過去に触りましたが、もちろんよくできていると思います。
が、私が今から GraphQL を導入するなら、以下の4つの理由から、やはり AWS AppSync を使うかなと思います。
- AWS サービスなので、他のサービスとの親和性が高い
- わざわざ GraphQL ようの箱を用意し、GraphQL と Apollo をインストールする必要がない
- AWS がパフォーマンスやセキュリティもカバーしてくれる（メンテナンス不要）
- AWS Amplify がカバーしてくれる
Apollo の魅力もありますが、目を瞑っても良いくらい AppSync の方が魅力に感じますね。
今回の登壇の反省
一番危惧していた 薄い内容 の登壇になってしまった。言い訳しようと思えばいくらでもできるのだが、あまり喋った内容について手を動かせなかったのが残念なところ。 次回別の機会に AppSync のハンズオンをどこかでやりたいと思っていますので、その時までに勉強しておきます。
ではでは。
