[Serverless Meetup Tokyo #14](https://serverless.connpass.com/event/143446/)で発表した資料。

1. AWSで開発するサーバレスAPIバックエンド
ServerlessMeetupTokyo#14
2019.09.19.
三宅暁

2. ⾃⼰紹介
三宅暁(ミヤケアキラ)
フリーランス(8⽉から)
フロントエンド
SPAをJS/HTML/CSSまるごと設計・実装できる程度の能⼒
Reactが得意、あとVueとAngular
バックエンド
サーバレス中⼼のAWS
Node.js
API設計
OpenIDまわり

3. ⾃⼰紹介
GitHub
AKIRA-MIYAKE
Blog
DreamofElectricCat
Twitter
@DreamOfEleCat

4. 主なサーバレス関連のライブラリ
serverless-import-swagger
OpenAPI形式のAPI定義からserverless.ymlのhandlerの定義を⽣成するツール
最近のバージョンアップで設定まわりが洗練されました
node-lambda-utilities
lambdaのhandlerのテストをしやすくするツール
contextやcallbackのモックの⽣成とhandlerの実⾏

5. 今⽇話すこと
AppSync+DynamoDB+Cognitoを使って、GraphQLのAPIバックエンドを作る
ノンコーディングで
デプロイが簡単にできて
なるべくベンダーロックインしないように

6. GraphQLorRESTful?
参考
GraphQLvs.REST
GraphQLはRESTの置き換えではない
個⼈的な考え
GraphQLの好きなところ
スキーマファーストの強制
宣⾔的なフィールドレベルのアクセス制御
GraphQLの気になるところ
キャッシュコントロール
エラーの表現

7. プロジェクトのサンプル
https://github.com/AKIRA-MIYAKE/aws-serverless-sample

8. ベンダーロックインしないために
Amplifyは使わない
フロントエンドがAWSにロックインしないように
ApolloClientを利⽤
Cognitoを⽤いるが、OpenIDProviderとして利⽤する
認可処理の拡張性を確保するため
@axa-fr/react-oidc-contextを利⽤

9. APIの仕様
メッセージの作成・取得・⼀覧・削除
取得・⼀覧はログインしなくても呼び出せる
⼀覧は作成⽇での降順
作成・削除はログインが必要
⾃分が作成したメッセージのみ削除できる

10. schema.graphql
type Query @aws_api_key @aws_oidc {
readMessage(id: ID!): Message
listMessage(limit: Int, nextToken: String): MessageCollection!
}
type Mutation @aws_oidc {
createMessage(input: CreateMessageInput!): Message!
deleteMessage(input: DeleteMessageInput!): Message
}
基本の承認モードをAPI_KEYに指定し、OPENID_CONNECTを追加
mutationはOPENID_CONNECTのみ許可し、認証状態を必須に

11. schema.graphql
type Message @aws_api_key @aws_oidc {
id: ID!
value: String!
createdBy: String!
createdAt: String!
}
createdByはCognitoが発⾏するsubを⽤いる

12. schema.graphql
type MessageKeyValue @aws_api_key @aws_oidc {
id: ID!
key: String!
value: String!
message: Message
}
type MessageCollection @aws_api_key @aws_oidc {
items: [MessageKeyValue!]!
nextToken: String
scannedCount: Int
}
MessageKeyValueはノンコーディングを達成しつつDynamoDBデータモデリング⻁の
巻：第参巻〜実践編〜の汎⽤的なGSIを実現するために⽣まれたもの
スキーマが不⾃然で1+Nになるため、速やかに修正されるべき箇所
パイプラインリゾルバの利⽤がおそらく適切

13. Mutation.createMessage.request.vtl
#set($id = $util.autoId())
#set($now = $util.time.nowISO8601())
#set($sub = $context.identity.sub)
#set($items = [...])
{
"version" : "2018-05-29",
"operation" : "BatchPutItem",
"tables" : {
"${DynamoDB}": $utils.toJson($items)
}
}
BatchPutItemを⽤いてクエリ⽤のレコードを同時に登録

14. Mutation.createMessage.request.vtl
#set($items = [
{
"id": $util.dynamodb.toString("${id}"),
"key": $util.dynamodb.toString("message"),
"value": $util.dynamodb.toString("${context.arguments.input.value}"),
"createdBy": $util.dynamodb.toString("${sub}"),
"createdAt": $util.dynamodb.toString("${now}")
},
{
"id": $util.dynamodb.toString("${id}"),
"key": $util.dynamodb.toString("message/createdBy"),
"value": $util.dynamodb.toString("${sub}")
},
{
"id": $util.dynamodb.toString("${id}"),
"key": $util.dynamodb.toString("message/createdAt"),
"value": $util.dynamodb.toString("${now}")
}
])

15. Query.listMessage.request.vtl
{
"version": "2017-02-28",
"operation": "Query",
"query": {
"expression": "#key = :key",
"expressionValues": {
":key": $util.dynamodb.toStringJson("message/createdAt")
},
"expressionNames": {
"#key": "key"
}
},
"index": "key-value-index",
"limit": #if($context.arguments.limit) $context.arguments.limit #else 10 #end,
"nextToken": #if($context.arguments.nextToken) "${context.arguments.nextToken}" #else null #end,
"scanIndexForward": false
}
key-value-indexをスキャンし、valueに⼊っているcreatedAtの値でのソートを実現
limitとnextTokenにデフォルト値をセット

16. MessageKeyValue.message.request.vtl
{
"version" : "2017-02-28",
"operation" : "GetItem",
"key" : {
"id": $util.dynamodb.toStringJson("${context.source.id}"),
"key": $util.dynamodb.toStringJson("message")
}
}
listMessageが返す、MessageKeyValueのmessageフィールドのマッピング
1件ごとにGetItemが実⾏されるため、1+Nに

17. Mutation.deleteMessage.request.vtl
{
"version": "2017-02-28",
"operation": "DeleteItem",
"key": {
"id": $util.dynamodb.toStringJson("${context.arguments.input.id}"),
"key": $util.dynamodb.toStringJson("message")
},
"condition": {
"expression": "createdBy = :createdBy",
"expressionValues": {
":createdBy": $util.dynamodb.toStringJson("${context.identity.sub}")
}
}
}
BatchDeleteではconditionが使えないため、メインのレコードのみの削除
パイプラインリゾルバの利⽤がおそらく適切

18. serverless-appsync-plugin
https://github.com/sid88in/serverless-appsync-plugin
AppSyncの設定を簡潔に定義してデプロイできるServerlessFrameworkのプラグイン
mappingTemplates(リゾルバ)は {type}.{field}.request.vtl と {type}.
{field}.respose.vtl のファイルをデフォルトで認識
vtlファイルで環境変数を設定できる
CloudFormationの出⼒を利⽤可能

19. serverless.yml
custom:
appSync:
substitutions:
DynamoDB: sls-sample-${env:ENV}
Batch系処理ではvtlで直接テーブル名の指定が必要
ステージごとにテーブル名が異なるため、環境変数として定義
vtlでは $DynamoDB のように、変数としてアクセス可能

20. serverless.yml
custom:
appSync:
additionalAuthenticationProviders:
- authenticationType: OPENID_CONNECT
openIdConnectConfig:
issuer: !Join
- ''
- - https://cognito-idp.ap-northeast-1.amazonaws.com/
- !Ref UserPool
CognitoをOPENID_CONNECT承認モードとして利⽤するための設定
issuerのURLがUserPoolのIDを含んだものとなるので、resourcesで出⼒された値を参照

21. CognitoUserPoolのアプリの統合の設定
アプリクライアントはCloudFormationで作れるが、アプリの統合は未サポート
この箇所だけコンソールかCLIからの設定が必要

22. アプリの統合/アプリクライアントの設定
「有効なIDプロバイダ」
「CognitoUserPool」を選択
「サインインとサインアウトのURL」
「コールバックURL」に http://localhost:3000/authentication/callback
を設定
@axa-fr/react-oidc-contextのデフォルト値
「サインアウトURL」に http://localhost:3000 を設定
「OAuth2.0」
「許可されているOAuthフロー」の「Authorizationcodegrant」を選択
「許可されているOAuthスコープ」の「phone」「email」「openid」
「profile」を選択
「openid」があれば動作はするはず

23. アプリの統合/ドメイン名
「AmazonCognitoドメイン」
「ドメインのプレフィックス」に任意の名前を設定
AppSyncは設定されたissuerの .well-known/openid-configuration から必要
な情報を取得するため、ドメイン名の指定は不要

24. フロントエンド
動作確認のためのシンプルなReactアプリ
ログイン/ログアウト
listMessageの結果の表⽰
createMessageの実⾏
deleteMessageの実⾏

25. ログイン/ログアウト(AppHeader)
const AppHeader = () => {
const { login, logout, oidcUser } = useReactOidc();
return (
<h1>AWS SLS Sample</h1>
{
oidcUser
? <div><button onClick={logout}>Logout</button></div>
: <div><button onClick={login}>Login</button></div>
}
{oidcUser && (
<span>sub(generated by cognito): {oidcUser.profile.sub}</span>
)}
);
};
@axa-fr/react-oidc-contextのフックを利⽤
Cognitoのページにリダイレクトされ、ユーザ登録まで処理してくれる

26. 認証⽅式の切り替え(ApolloContext)
const client = useMemo(
() => {
if (oidcUser && oidcUser.id_token) {
return new ApolloClient({
uri: process.env.REACT_APP_GRAPHQL_URL,
request: operation => {
operation.setContext({ headers: { Authorization: `${oidcUser.id_token}` },
});
},
});
} else {
return new ApolloClient({
uri: process.env.REACT_APP_GRAPHQL_URL,
request: operation => {}
operation.setContext({ headers: { 'x-api-key': process.env.REACT_APP_GRAPHQL_API_KEY },
});
},
});
}
},
[oidcUser]
);
ログイン状態に応じて、クライアントを切り替えるコンテキストを定義

27. フロントエンドのベンダーロックイン
GraphQL、OpenID共にAWSに依存しない仕組みにしているため、最低限の修正でエン
ドポイントの変更が可能
OpenIDの設定値の変更
ApolloContextのヘッダーの変更

28. 実サービスで利⽤するために検討が必要な箇所
AppSyncのAPI_KEY承認モードの利⽤
定期的な再発⾏を⾏い、キーを返すAPIを実装する
Cognitoに匿名ユーザを登録し、sub値で判断する
ClientCredentialsGrantフローで取得したトークンを返すAPIを実装する(そのトー
クンが利⽤可能か未検証)
厳密なログアウト
@axa-fr/react-oidc-contextはトークンを削除することでログアウト
厳密な制御を⾏うなら、ログアウトエンドポイントを⽤いてCognito側のログアウト
も必要
ホストされたサインアップ、サインインページとリダイレクト
ADMIN_NO_SRP_AUTHを⽤いてそれぞれの処理を⾏い、取得されたトークンを返
すAPIを実装する

29. まとめ
AppSync+DynamoDB+Cognitoを使えば、ノンコーディングでGraphQLのAPIバック
エンドを作ることができる
パイプラインリゾルバを利⽤すれば、実サービスでもある程度までは対応できそう
serverless-appsync-pluginを利⽤することで(ほぼ)⾃動でデプロイが可能
AWSにほとんど依存しないフロントエンドの開発も可能
⾮ログイン状態でのAppSyncへのアクセス制御は検証が必要