AWS Amplify
けっこう良い
〜でも NoSQLとかLambda がピーキーなので
トータル微妙〜
目次
- Amplify でこんなの作ってます
- Amplify って何？
- Amplify の良い点
- Amplify の悪い点
- 良い点/悪い点を総合的に見て
- （おまけ）個人開発を２ヶ月してみて
Amplify でこんなの作ってます
できること
- グループごとに日報の質問を設定
- 指定した時間にリマインド
- 回答した日報を、指定したチャンネルに自動投稿
- 前回の日報をコピーして回答
- グループ/回答日時の検索
システム構成
DEMO
Amplify って何？
- 革新的なアプリケーションを構築する
-
数分でバックエンドを設定する
-
容易にデプロイおよびスケーリングする
「…つまり何？」
- サーバーレスなWeb開発で使えるAWSサービスのセット
- Lambda, AppSync, DynamoDB, API Gateway, Cognito, (React|Vue|Angular) ...
- "amplify add {サービス名}" で、サービスがクラウド上に立ち上がる
- CLIによる、AWSサービスの作成,変更,削除
- Infra as Code による、インフラの管理
- 「自分でマネコンから逐一設定しなくても、コマンド一発で準備してくれるやーつ」
２ヶ月使ってみた所感
これ全部（の雛形）がコマンド一発で作れる！
Amplify の良い点
-
AppSync 良い！
-
Lambda 良い！
-
Amplify Console 良い！
AppSync 良い！① - 1
type UserGroup @model {
id: ID!
group_code: String!
group_name: String!
slack_team_id: String!
slack_user_name: String!
slack_user_id: String!
user_slack_channel_id: String!
group_slack_channel_id: String
post_schedule_hour_utc: Int
slack_access_token: String!
}こんなGraphQLスキーマを作ると、DynamoDBテーブルが作成される！
カオスなNoSQLに秩序が！！
AppSync 良い！① - 2
DynamoDBはこんな感じ
スキーマと一致
AppSync 良い！② - 1
export const teamsBySlackTeamId = `
query TeamsBySlackTeamId(
$slack_team_id: String
$id: ModelIDKeyConditionInput
$sortDirection: ModelSortDirection
$filter: ModelTeamFilterInput
$limit: Int
$nextToken: String
) {
teamsBySlackTeamId(
slack_team_id: $slack_team_id
id: $id
sortDirection: $sortDirection
filter: $filter
limit: $limit
nextToken: $nextToken
) {
items {
id
slack_team_id
name
is_premium
failed_payment
slack_access_token
createdAt
updatedAt
}
nextToken
}
}
`;こんなクエリが自動生成されるので、これを叩くだけでCRUDできる。
レポジトリ層が勝手に作られる！
AppSync 良い！② - 2
const {
data: {
teamsBySlackTeamId: { items: teams },
},
} = await client.query({
query: gql(teamsBySlackTeamId),
variables: {
slack_team_id: response.data.team.id,
},
});呼び出し側ではこんな感じに値が取れる！
素敵！！
Lambda 良い！
Lambda の良さがそのまま活かせる！
- Express を使ったAPIサーバー
- Cloudwatch Alerm による cron
- ステートレスでメンテ不要
- 従量課金
ただ、Lambdaの辛さもそのままだよ！（後述）
Amplify Console 良い！
dev/prod環境を作るのが楽
- masterブランチをプッシュしたら、prod更新
- インフラ構成の変更がコミットされてたら、インフラも更新
Amplify の悪い点
-
NoSQL 辛い！
-
Lambda 辛い！
-
Cognito 微妙！
NoSQLおすすめリンク
募集中
（なんかどれも難しかったりで、いい感じのドキュメント無いんですよね…）
NoSQL 辛い！
（別にamplify 関係ないんだけど）
- Joinがない
- RDBのイメージでテーブル分けたらN+1
- 非正規化/非直交性
- データをモデル毎にするのはアプリ層で変換
- バグ、バグ、バグ、、、
- 強整合性でなく結果整合性
- トランザクションが有る？無い？
Lambda 辛い！
（別にamplify 関係ないんだけど）
- コールドスタート
- 30分ほどアクセス無いと、コンテナ廃棄
- 次はコンテナ作成からスタートなので遅い
- さらにVPC内に作るとさらに遅い
- RDSとの相性悪い
- 意図しないリトライに備えたべきとう性の担保
- SQSトリガー等の非同期の場合は「成功した」場合でもリトライの可能性
Lambda おすすめリンク
Cognito 辛い！
- SPAだからJWT認証、トークンはローカルストレージに保存される
- アクセストークンは百歩譲ってもローカルストレージでもヨシとしよう
- リフレッシュトークンもローカルストレージっておかしい！怖くて使えないよ！！
- じゃあクッキーで…と思ったら、クッキーは非対応
普通のSPAやるなら、auth0がおすすめ！
auth0-spa-js ってライブラリが素直で使いやすい
Cognito （認証）
おすすめリンク
良い点/悪い点を総合的に見て
- とにかく予算が無い
- 個人開発
- AWSマニア
が当てはまるならアリ！
求められるスタックが広いから、技術好きなら楽しいよ！
でもピーキーさが強いので「ECS+RDS」
が王道かもね。
（余談）Firebase とはどっちが良いの？
- Amplify は AWS らしく「何でもできるけど、やろうとしたら大変
- CloudFormation知らないと、IAMで詰みそう
- GraphQLのスキーマがあるだけ、DBがちょっと分かりやすい
- でも結局NoSQLだしなぁ〜
- 認証周りはFirebaseの方が良さそう
（おまけ）
個人開発を２ヶ月してみて
- 言語とかFWとか技術的なアーキテクトは何でも良い
- イケてるの使ってもユーザーに関係ないし！
- 「枯れた技術」は大事。NestというJSフレームワーク使ったけど、ORM微妙だったりした。
- 「とにかくバグを減らす」という前提で、選定とか実装とかしたら良いんじゃないかな。
- ０→１でも開発内容は普段と変わらない
- インフラと認証周りは知識ついたけど、他はそんなに変わんない
- かけた時間としては フロント > サーバー > インフラ > その他
（つづき）
- 「何を作るのか」って超ムズイ。「どう作るのか」って超かんたん。
- １人でするより３人、３人より１００人の方がプロダクトは良くなる。１人で全部できる必要はない。専門性って大事なんだ（今更）。
- 次はデザインやりたいな〜。「技術つよつよデザイナー」になりたい。
deck
By kon_shou
