AWS Amplify
けっこう良い
〜でも NoSQLとかLambda がピーキーなので
トータル微妙〜
目次
- Amplify でこんなの作ってます
- Amplify って何?
- Amplify の良い点
- Amplify の悪い点
- 良い点/悪い点を総合的に見て
- (おまけ)個人開発を2ヶ月してみて
Amplify でこんなの作ってます
できること
- グループごとに日報の質問を設定
- 指定した時間にリマインド
- 回答した日報を、指定したチャンネルに自動投稿
- 前回の日報をコピーして回答
- グループ/回答日時の検索
システム構成
DEMO
Amplify って何?
- 革新的なアプリケーションを構築する
-
数分でバックエンドを設定する
-
容易にデプロイおよびスケーリングする
「…つまり何?」
- サーバーレスなWeb開発で使えるAWSサービスのセット
- Lambda, AppSync, DynamoDB, API Gateway, Cognito, (React|Vue|Angular) ...
- "amplify add {サービス名}" で、サービスがクラウド上に立ち上がる
- CLIによる、AWSサービスの作成,変更,削除
- Infra as Code による、インフラの管理
- 「自分でマネコンから逐一設定しなくても、コマンド一発で準備してくれるやーつ」
2ヶ月使ってみた所感
これ全部(の雛形)がコマンド一発で作れる!
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の方が良さそう
(おまけ)
個人開発を2ヶ月してみて
- 言語とかFWとか技術的なアーキテクトは何でも良い
- イケてるの使ってもユーザーに関係ないし!
- 「枯れた技術」は大事。NestというJSフレームワーク使ったけど、ORM微妙だったりした。
- 「とにかくバグを減らす」という前提で、選定とか実装とかしたら良いんじゃないかな。
- 0→1でも開発内容は普段と変わらない
- インフラと認証周りは知識ついたけど、他はそんなに変わんない
- かけた時間としては フロント > サーバー > インフラ > その他
(つづき)
- 「何を作るのか」って超ムズイ。「どう作るのか」って超かんたん。
- 1人でするより3人、3人より100人の方がプロダクトは良くなる。1人で全部できる必要はない。専門性って大事なんだ(今更)。
- 次はデザインやりたいな〜。「技術つよつよデザイナー」になりたい。
deck
By kon_shou
deck
- 92