Day 2: INTERFACE from APIdays

録画は後日共有してくださるそうなので、あとでまた見ていないものも見ておきたいです。

Interface June 30 & July 1, 2020 | apidays Global

Microservices Communication Patterns with gRPC / Kasun Indrasiri

マイクロサービスへのgRPCへの取り込みパターン。QAで「全部をgRPCでやるのはアンチパターン、gRPCにこだわらず適切なスタイルのAPIを選ぶべき」と行ったのが印象的。

Application Connectivity: Leveraging Service Mesh to Build Modern Applications / Marco Palladio

Service Meshの特徴とAPI Gatewayとの使い分けについて。API Gatewayがサービスやシステムの入り口に位置するのに対し、Service Meshはマイクロサービスの中に入っていくものだという文言がなるほどなと思いました。

The Next API Strategy: Going Borderless / Ronnie Mitra

もはや組織の外のAPIを使うことは当たり前であって、社外社内の区別にこだわらずにリソースとして管理することが重要ですよというお話。

と書くと特徴のない話に聞こえるのですが、実際にはAPIを利用者として活用したときに考えなければいけない技術戦略とガバナンスはどう言った内容があるかとか、そのAPIが組織外のもの、組織内のものどちらであっても考えなければいけないことに代わりはないよという話で、APIを活用したプロダクト作りをする時の観点を体系的に説明するものでした。とても良かったです。

Building a Faster Checkout Experience at PayPal with GraphQL / Vishakha Singh

PayPalでのGraphQLの活用事例。

RESTだったものをGraphQLになぜ作り直したのかという話が面白い。確かにその通りだと思いました。

RESTだとクライアントが作成された時点でAPIのインターフェースは大きく動かせない。

GraphQLのインターフェースはクエリ言語のようなもので、APIサーバー側ではJOINの定義など、データモデルを定義しておけば良い。そのデータモデルに合わせてGraphQLのリクエストのBodyを書けば必要なデータが出てくる。データモデルそのものはそれほど変わるものではない。多少API側に変更があってもクライアントには影響を与えないので、API側の実装もクライアント側の実装も変えやすく、より開発を高速化できる。だから採用したんだとのこと。

GraphQL for Cities / Roy Derks

アムステルダム市が主導でITの活用をしていて、その中でGraphQLを活用している事例について。

市で採用しているエンジニアの数が冒頭にあったのですが、メモし忘れたのが残念です。

アムステルダム市のWebページに行くとアプリケーションの活用とかがNewsに載ってました。

Automating Style Guides for REST, gRPC or GraphQL / Phil Sturgeon

APIを設計する際にプロダクトごとに自由に設計していると、例えばAPIクライアント開発者が複数のAPIプロダクトを使って何かを作ろうとした時にフラストレーションが溜まる。したがってAPIスタイルガイドを作り、会社単位で一貫性のあるエクスペリエンスを提供すると良い。例えばURIの命名規則をどうするか、インターフェースをどうするか、クエリをどうするかとか。