REST API、gRPC、GraphQL 触ってみた【2023年12月開催勉強会資料】

クラウドネイティブの旅に出よう:
REST API、gRPC、GraphQL触ってみた
IBM Tech/Developer Dojo
2023/12/06
Copyright ©2023 NS Solutions Corporation, IBM Corporation. 1

Beyond the Twelve-Factor App回の再掲

本日の目標
• REST API、gRPC、GraphQLの違いと使いどころ
が、なんとなく分かり、語れるようになる！

本日のアジェンダ
1. オープニング
2. REST APIのご紹介
3. gRPCのご紹介
4. GraphQLのご紹介
5. QA・クロージング

はじめに
当イベントは日本IBMおよび日鉄ソリューションズの有志エンジニアによって企画された勉強会です。
クラウドネイティブやマイクロサービスなどのテーマを中心に、今後も色々な勉強会・イベントを開催する予定です。
本勉強会の内容は、エンジニア個人の見解であり、所属する企業の公式見解ではありません。
セッション中はマイクミュートでの参加にご協力お願いします。
本イベントは録画してアーカイブ公開する予定ですので、その点ご了承ください。
本発表で利用している製品の名称およびロゴは下記の個人、組織または企業の商標となります。
OpenAPI（旧Swagger）・gRPCは、米国及びその他の国におけるThe Linux Foundationの商標または登録商標である。
GraphQLは、米国及びその他の国におけるGraphQL Foundationの商標または登録商標である。
Javaは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。
IBM、WebSphere MQ は、IBM Corporation の登録商標または商標です。
NS（ロゴ）、NSSOL、NS Solutions は、日鉄ソリューションズ株式会社の登録商標です。
その他本文記載の会社名及び製品名は、それぞれ各社の商標又は登録商標です。

自己紹介
＜所属＞
日本IBM システムズ・エンジニアリング
<経歴>
2016年に日本IBMシステムズ・エンジニアリングに入社
スクラムマスターとしてweb/モバイルアプリ開発を経験
し、2021年からIBMでカスタマーサクセスマネージャー
<趣味など>
ペットの猫と遊ぶ、ハッカソン参加
Copyright ©2023 NS Solutions Corporation, IBM Corporation.
佐川洵貴（さがわじゅんき）
6

自己紹介
＜所属＞
日鉄ソリューションズシステム研究開発センター
<経歴>
2019 年に日鉄ソリューションズに新卒入社。
スクラムでのクラウドネイティブ案件においてアーキテ
クト兼開発者を経験。
<趣味など>
日本酒、（非電源含む）ゲーム、ごま豆腐
喜多司（きたつかさ）
7

望月雄登（もちづきゆうと）
＜所属＞
日鉄ソリューションズシステム研究開発センター
<経歴>
2022 年に日鉄ソリューションズに新卒入社。
BFF(Backend For Frontend)構成全体の監視を導入す
る案件を担当。
<趣味など>
アニメ、ゲーム、将棋
自己紹介
8

3. gRPCのご紹介

REST API

APIとは
• Application Programing Interface
– インターフェース：二つの物事の間を仲介する窓口となるもの
– アプリケーションとミドルウェアを繋げるインターフェース（やりとりを行うために作られた受け口）
• Web API
– 外部サービスとの連携できる（同一システムではなく、他のシステムの機能を使う）
– 種類はいろいろあるが、web APIという場合はほぼ【REST API】のこと
– 他のサービスの機能を使うインターフェース
サーバー外部サービスA
A
P
I
ブラウザでアクセス！
ページどうぞ
これに関するデータくれ！
どうぞ〜
受け取ったインプット
をもとに処理を行い、
結果を返す
A
P
I
外部サービスB

データ通信の歴史
1960
RPC
リモートプロシージャコール
ネットワークを通じ、
別のコンピュータ上で処理
1999
SOAP
マイクロソフト発
Simple Object Access Protocol（SOAP）
HTTPプロトコルを用い、XML形式メッセージを通信
2000
REST
REpresentative State Transfer
本日説明
2015
2016
GraphQL
本日説明
gRPC
本日説明

REST APIとは？
• コンピューター同士を接続し、分散処理を実現するための設計思想の一つ
• REpresentative State Transfer
• 4原則
1. アドレス可能性 (Addressability)
2. 統一インターフェース (Uniform Interface)
3. ステートレス性 (Stateless)
4. 接続性 (Connectability)

REST APIの基本
• HTTP通信でリクエストを送信
• リクエスト先はURLで指定
• JSONデータを返却
ステータス意味
200番台正常時
300番台リダイレクト時
400番台クライアント側でのエラー時
500番台サーバー側でのエラー時
HTTPメソッド利用用途
GET リソースの取得
POST リソースの新規追加
PUT リソースの更新
DELETE リソースの削除
http://test.com:8443/user/age?name=sagawa
GETリクエストの例)
scheme ホスト名パスクエリパラメーター
http方式で【scheme】、test.comサーバー【ホスト名】に通信し、ユーザーの
年齢情報をください（パス）、インプットとして、name=sagawaを渡します。
HTTPリクエストを受け取ったサーバーは、インプット情報を使い、
データベースなどの検索をした結果【age】を200番と一緒に返す

ExpressにおけるREST API開発例
var express = require('express');
var router = express.Router();
//api/profileにリクエストがきたときの処理
router.get('/profile', function(req, res, next) {
res.json({
'name': 'Junki Sagawa',
'age': 29
'hobby': 'football'
});
});
router.get ('/hoge', function(req, res, next) {
//todo
});
module.exports = router;
/api/hogeにきたときの処理。
各APIをURLおよびメソッドごとに作成して
いく
メソッドが異なれば同じURLで指定可能
router.get(‘/hoge’)とrouter.post(‘/hoge’)は異
なるAPI
/api/profile（URI）にHTTPリクエストがきた
ときの処理。
返すデータはjson形式で記載

REST APIで実装
フロント開発チームA
API1
API2
API開発チームB
API1
API開発チームC
このデータも返却してほしい！
Excel仕様に則ったリクエスト
エラーになる...。
昨日デプロイした更新を
Excel定義書に更新忘れてた
フロント – バックエンド通信バックエンド間通信、マイクロサービス間通信
アプリ/BFF
追加仕様がどんどんくる。
Python Node.js

REST APIで実装
フロント開発チームA
API1
API2
API開発チームB
API1
API開発チームC
このデータも返却してほしい！
Excel仕様に則ったリクエスト
エラーになる...。
昨日デプロイした更新を
Excel定義書に更新忘れてた
フロント – バックエンド通信バックエンド間通信、マイクロサービス間通信
アプリ/BFF
追加仕様がどんどんくる。
Python Node.js
スキーマ駆動開
のススメ

OpenAPI概要
• OpenAPI仕様（OAS）
– プログラミング言語にとらわれない
標準的なインタフェース記述の定義
• OpenAPIドキュメント
– OpenAPI仕様に準拠して
APIまたはAPIの要素を定義したテキストファイル
– yaml形式、json形式で記述
• OpenAPI周辺ツール
– OpenAPIドキュメントのエディター
– OpenAPIドキュメントの可視化ツール
– 定義からコードの自動生成！
＜OpenAPIドキュメント＞
＜可視化＞

スキーマ駆動開発の流れ
19
OpenAPI仕様可視化
stab API
API1
API2
バックエンド開発B＆C
フロント開発A
スタブ自動生成
雛形自動生成
• FastAPI
• Django
• Express なんでもござれ
API開発を待たずにスタブと通信しながら開発
コール先を
スタブから本APIへ
切り替える
ダミーデータ
スキーマに従い
リクエスト
アプリ v1.0
OpenAPIエディター

REST API – スキーマ駆動開発まとめ
RESTはHTTP通信でGETやPOST、DELETEといったリクエストを送信して、JSON形式のデータを受け取る
APIの定義は、ExcelではなくOpenAPIという仕様で書くと調子が良い
スタブAPIや、APIの雛形コードは自動生成できちゃう
フロント – バックエンドの通信だけでなく、マイクロサービス間のやり取りもREST APIで実装できる

ところがどっこい、
REST APIにも課題があります。

RESTの課題
オーバーフェッチ: 過剰な取得
• 例: https://swapi.co/api/people/1/にGETリクエストを投げる
{
"birth_year": "19BBY",
"created": "2014-12-09T13:50:51.644000Z",
"edited": "2014-12-20T21:17:56.891000Z",
"eye_color": "blue",
"films": [
"https://swapi.co/api/films/2/",
"https://swapi.co/api/films/7/"
],
"gender": "male",
"hair_color": "blond",
"height": "172",
"homeworld": "https://swapi.co/api/planets/1/",
"mass": "77",
"name": "Luke Skywalker",
"skin_color": "fair",
"species": [
"https://swapi.co/api/species/1/"
],
"starships": [
"https://swapi.co/api/starships/12/",
"https://swapi.co/api/starships/22/"
],
"url": "https://swapi.co/api/people/1/",
"vehicles": [
"https://swapi.co/api/vehicles/14/",
"https://swapi.co/api/vehicles/30/"
]
}
本来欲しいデータ
{
"gender": "male",
"hair_color": "blond",
"height": "172",
"name": "Luke Skywalker",
}

RESTの課題
アンダーフェッチ: 不足する取得
• 前の例で、出演映画タイトルの一覧を取得する場合
• https://swapi.co/api/people/1/にGET
↓
• 以下のそれぞれにGET
"films": [
"https://swapi.co/api/films/7/"
]
23
filmからのレスポンス
{
"title": "The Empire Strikes Back",
"episode_id": 5,
"opening_crawl": "……",
"director": "Irvin Kershner",
"producer": "Gary Kurtz, Rick McCallum",
"release_date": "1980-05-17",
"characters": [
"https://swapi.co/api/people/1/",
"https://swapi.co/api/peole/2/",
"https://swapi.co/api/people/26/"
],
"planets": [
//…… 大量のルートのリスト
],
"starships": [
],
"vehicles": [
],
"species": [
],
"created": "2014-12-12T11:26:24.656000Z",
"edited": "2017-04-19T10:57:29.544256Z",
"url": "https://swapi.co/api/films/2/"
}

RESTの課題
エンドポイント管理
• 過大・過小の過大を解決しようとユースケース毎にAPIを作ると、エンドポイントがどんどん増える
• 多くの大規模アプリケーションでは、HTTPリクエストの回数を減らすための最適化されたエンドポイントを作
成しています
• このデータも欲しい！→ 既存APIはすでに利用されているから別でAPI一本増やすかあ
• /api/movie/title
• /api/movie/detail
• /api/movie/charactors
• .....
図足す

RESTの課題
双方向通信は無理
• 通常、HTTP 1.1に基づいて構築されており、リクエスト・レスポンス型の通信モデルとなる
• HTTP2でサポートされている双方向のストリーミング通信はできない

3. gRPCのご紹介

gRPC

gRPC 概要
• Google 製の RPC で、OSS
– gRPC の g は、general-purpose の g？
• gRPC – Wikipedia
• 型定義に Protocol Buffers を使用していて、各言語毎に型定義のソースコードを生成できるため、
サービス間で異なる言語を使っていたとしても翻訳が不要
• HTTP/2 を使っているため高速

REST の課題（再掲）
• パフォーマンス低下に繋がる
– オーバーフェッチング
– アンダーフェッチング
• エンドポイントの数が多くなり管理が大変
• 双方向通信はできない

gRPC のアプローチ
• JSON のような人間に分かりやすい形式ではなく、バイナリをやり取りすることで通信を軽量化
• エンドポイントは一つ
• HTTP/2 に則ることで双方向通信もカバー

GraphQLとの差異
• GraphQL も gRPC もどちらも、REST API よりもパフォーマンスを改善するが
– GraphQL はフロントエンド開発寄りの発想
– gRPC はバックエンド開発寄りの発想
• ブラウザから gRPC リクエストを送る技術は発展途上
– grpc-web

gRPC の開発フロー概要
• .proto ファイルを作成
– Protocol Buffers というスキーマ言語を使ってスキーマを定義
• .proto ファイルから各種言語の型定義を生成
– Protoc コマンドが各種言語に対応したファイルを自動生成
• 生成されたファイルを import してアプリケーションを実装

Unary RPC
• 使用例
– 通常の REST API と同様
• GET、POST、PATCH、DELETEメ
ソッドなどで問題なく実現されて
いたもの

Server Streaming RPC
• 使用例
– ファイルのダウンロード
– バッチ処理
– サーバからのリアルタイム通知

Client Streaming RPC
• 使用例
– ファイルのアップロード
– サーバが逐次処理可能なもの

Bidirectional Streaming RPC
• 使用例
– リアルタイム性を要求する処理
• オンラインゲーム
• チャット

デモ・ハンズオン
• https://killercoda.com/tofuchic/scenario/grpc-quickstart
– 次のような流れを体験できるハンズオンです
• gRPC のサンプルアプリをサーバ・クライアントでそれぞれ動かす
• スキーマである .proto ファイルを編集する
• 新しいスキーマに沿ってクライアントアプリを更新して動かす
• サーバアプリも更新して動かす
– 時間の都合上ハイペースで進めるため、
まずはデモとして見ていただき、
後からゆっくりハンズオンに取り組んでいただいても大丈夫です

gRPC のまとめ
REST API の課題 gRPC のアプローチ備考
パフォーマンスが出な
い場合がある
バイナリ通信によって
高速化
ネットワークレイテンシは削減できるものの、様々なサービス
に向けた汎用的なメソッドを実装するとデータ量が増え、各
サービス内の処理時にメモリ不足に陥る可能性もある
エンドポイント管理が
大変
1 つのエンドポイント
に対して複数のメソッ
ドを実装していく
エンドポイントは 1 つで済むが、代わりに様々なサービス向け
に独自のメソッドを実装することになる可能性もある
また、ブラウザからの呼び出しはまだ発展途上
双方向通信ができない HTTP/2によって4つの
通信パターンを網羅し、
双方向通信も可能
general-purposeというだけあってあらゆるユースケースに対応
できるポテンシャルがある

3. gRPCのご紹介

GraphQL

GraphQLとは
 APIのための問い合わせ言語
 使用例: SWAPI（https://graphql.org/swapi-graphql/）
query {
person(personID:5) {
name
birthYear
created
filmConnection {
films {
title
}
}
}
}
{
"data": {
"person": {
"name": "Leia Organa",
"birthYear": "19BBY",
"created": "2014-12-10T15:20:09.791000Z",
"filmConnection": {
"films": [
{
"title": "A New Hope"
},
{
"title": "The Empire Strikes Back"
},
{
"title": "Return of the Jedi"
},
{
"title": "Revenge of the Sith"
}
]
}
}
}
}

GraphQLの設計原則
 階層構造 GraphQLのクエリは階層構造になっています。フィールドは他のフィールドの入れ子になり、クエリはレスポ
ンスと同じ構造を取ります。
 プロダクト中心 GraphQLは、データを必要とするクライアントの言語やランタイムに従って実装されます。
 強い型付け GraphQLサーバはGraphQLの型システムに保証されています。それぞれのフィールドは固有の型を持ち、
バリデーションされます。
 自己参照 GraphQL言語はGraphQLサーバ自身の型システムを問い合わせられるようにできています。

GraphQLの性質
 GraphQLは仕様にすぎず、それ以上のアーキテクチャの決定権は開発者にあります。
 エンドポイントは1つです。
 クエリで参照できるすべてのフィールドが型で定義されています。
 クエリが入れ子になっている場合は、実行時に関連するオブジェクトをすべて探し出します。つまり、1回のHTTPリクエ
ストで2つの異なる種類のデータを受け取ることができます。
 多様な言語でのサーバー実装のライブラリが存在します。(C#、Clojure、Elixir、Erlang、Go、Groovy、Java、
JavaScript、.NET、PHP、Python、Scala、Ruby、...)

構成例
クライアント
(エンドユーザ等)
graphQLサーバ
マイクロサービス
実行、DB
REST API
実行、DB
クエリ
クライアント
(エンドユーザ等)
graphQLサーバ
DB
クエリ
gRPC
実行、DB

GraphQLの現状
 採用企業
 GitHub、ニューヨーク・タイムズ、IBM、X(旧Twitter)、Yelp
 カンファレンス
 GraphQL Summit、GraphQL Finland、GraphQL Europe
 クライアントツール
- Relay（https://facebook.github.io/relay/）
- Apollo（https://www.apollographql.com/）

GraphQL実現のための構成
リゾルバ
var photos = []
const resolvers = {
Query: {
totalPhotos: () => photos.length
},
Mutation: {
postPhoto(parent, args) {
photos.push(args)
return true
}
}
}
スキーマ
type Photo {
id: ID!
name: String!
url: String!
description: String
}
type Query {
totalPhotos: Int!
allPhotos: [Photo!]!
}
type Mutation {
postPhoto(
name: String!
description: String
category: PhotoCategory=PORTRAIT
): Photo!
}
schema {
query: Query
mutation: Mutation
}
クエリ
query {
totalPhotos
allPhotos
}

GraphQLのクエリの書き方
 ルート型
- オペレーションに対応する型。最上位階層に必ず存在する型。
- Query(取得), Mutation(操作), Subscription(監視)
 フィールド
 選択セット
 クエリ引数
query {
name
birthYear
created
filmConnection {
films {
title
}
}
}
}
サブスクリプション
WebSocketによるリアルタイム通信で、該当のミューテーションを検知すると変更後のデータを取得
(クエリとミューテーションはHTTP通信)
例: 新規投稿のプッシュ通知

GraphQLの導入時に意識すること
 セキュリティ
- 1つのクエリで膨大なリクエストが可能
- 対策例
- タイムアウト、データ量制限、深さ制限、複雑度制限
- モニタ (Apollo Engine)

GraphQLのデメリット
 学習・実装コスト
- スキーマの定義など、従来よりも大変な面がある
 パフォーマンス
- 膨大なリクエストに対するサーバ側のパフォーマンス維持を考慮する必要がある
 セキュリティ
- 従来のAPIよりも自由度が高い分、不正なクエリが実行される可能性が高くなる
 キャッシュ
- 毎回異なるクエリが実行されると、キャッシュが使えない

ハンズオン
 SWAPI (https://graphql.org/swapi-graphql/)
 スキーマ: https://github.com/graphql/swapi-graphql/blob/master/schema.graphql

適当なクエリ
a

すべての人を取得
query {
allPeople {
people {
name
}
}
}

複数のクエリ
query {
allPeople {
people {
name
}
}
}
query {
allFilms {
films {
title
}
}
}

該当する人のみを取得
query {
name
birthYear
created
}
}

クエリの入れ子
query {
name
birthYear
created
filmConnection {
films {
id
title
}
}
}
}

複数の入れ子
query {
name
birthYear
created
filmConnection {
films {
id
title
characterConnection {
characters {
name
}
}
}
}
}
}

GraphQLの名前の由来
person
person
person
film
film
film
name
Leia Organa title A New Hope
・・・
・・・

person film
film
name
Leia Organa title A New Hope
・・・
・・・

person
film film
name
Leia Organa
title A New Hope
・・・

GraphQL のまとめ
REST API の課題 GraphQL のアプローチ備考
パフォーマンスが出な
い場合がある
クエリとその階層構造の
自由度によってオーバー
フェッチとアンダー
フェッチを解決
たとえば膨大な計算量を要する危険なクエリが実行できないよ
う、複雑度制限をかけるなど、GraphQL サーバに対してセ
キュリティ設定を施すといった対応が必要
エンドポイント管理が
大変
1 つのエンドポイントに
対して複数のリゾルバを
実装していく
リゾルバ実装に関する学習コストが必要
双方向通信ができない Subscription によるサー
バからクライアントへの
リアルタイム通知をサ
ポート
gRPC における Server Streaming RPC 相当の機能。そのため、
Client Streaming RPC や Bidirectional Streaming RPC 相当の
通信は実現できない

3. gRPCのご紹介

本日のまとめ
 “12 Factor App” をクラウドネイティブに対応できるように発展させた15 項目の方法論である
“Beyond the Twelve-Factor App” には、API First が追加されています
 APIと一口に言っても、最近はREST APIだけでなく、gRPCやGraphQLもよく耳にします
 そこで本日は、REST API、gRPC、GraphQLの概要をデモを交えながらお伝えしました
 Call to Action!
- アプリケーション開発時にREST API以外も選択肢として持ちましょう
- 興味がある方は手を動かしてみましょう

Q&A
• GraphQL を利用する際は、メソッドの共通化などは難しいのでしょうか？それともよく利用する形のものは、
スキーマ層に別途用意するなどの手法を取るのでしょうか？
– クエリの共通化という意味であれば、fragment という機能があります。これは、いくつかのクエリで共通
して取得するデータを一度だけ定義すれば、各クエリからその定義を参照することのできる機能です。
– 型に関する共通化で言うと、interface や union、その他 directives といった共通化に使える機能が用意され
ています。詳しくは GraphQL のスキーマについて調べてみてください。
• REST API には 4 つの課題があり、gRPC や GraphQL はその内いくつかの課題を解決している、とおっしゃっ
ていましたが、具体的にそれぞれどの課題を解決していますでしょうか？
– gRPC が解決している点
• パフォーマンス：オーバーフェッチとアンダーフェッチを直接的に解決することはしませんが、バイナ
リ通信によってパフォーマンスを向上できます。
• エンドポイント管理: エンドポイントは1つです。
• 双方向通信は無理: 双方向通信を含む4 つの通信パターンを紹介しました。
– GraphQL が解決している点
• オーバーフェッチ: クエリで取得するデータを絞り込めます。
• アンダーフェッチ: クエリを入れ子にして呼び出し回数1回のみで欲しいデータを取得できます。
• エンドポイント管理: エンドポイントは1つです。

Q&A
• GraphQL にはセキュリティ上の課題がある、とのお話でしたが、プロダクトやサービスの開発において、どの
ような対策をされているでしょうか？
– 一例としてこちらの記事をご紹介いたします。
• 「リスクを伴う設定」「悪意のあるクエリ」に対して然るべき対策を取った上で、GraphQL 対応の
WAF を利用することで多層防御することが挙げられています。
• セキュリティの問題に関連して、プロダクトやサービスの開発では、フロントエンド（React など）から直接
GraphQL を呼び出すのが一般的でしょうか？それともセキュリティを考慮してサーバを 1 つ挟むなどの対応が
必要でしょうか？
– フロントエンドから GraphQL サーバを呼び出すのが一般的です。
– 但し、上述したように「リスクを伴う設定」「悪意のあるクエリ」への対策を GraphQL サーバに施した上
で、場合によっては間に WAF を挟むというアーキテクチャにすることもあるようです。

We are hiring!!
• 日鉄ソリューションズでは、
クラウドネイティブ技術を用いて
お客様の DX を推進する仲間を募集中です。
• ご興味ある方は、
ぜひお問い合わせください。
弊社人事より、ご連絡を差し上げます。
• 🔍「NSSOL キャリア採用」
• 採用ページ：
• https://www.nssol.nipponsteel.com/re
cruit/careers/

REST API、gRPC、GraphQL 触ってみた【2023年12月開催勉強会資料】

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to REST API、gRPC、GraphQL 触ってみた【2023年12月開催勉強会資料】

Similar to REST API、gRPC、GraphQL 触ってみた【2023年12月開催勉強会資料】 (20)

Recently uploaded

Recently uploaded (8)

REST API、gRPC、GraphQL 触ってみた【2023年12月開催勉強会資料】