AWS DAS 要点整理

# 背景
Terraformではmoduleを使用する際、以下の様にローカルから呼び出す方法が一般的とされている。

```
module "sample-code" {
    source = "../modules/iam/ecs_taskrole"
}
```

確かにこの方法でも取得自体は可能だが、問題として参照先のmoduleを修正した場合、参照元箇所に影響を及ぼす可能性が少なからず発生する。

```
###################################
# 以下の内容であればエラーなく作成が可能。
###################################
module "sample-code" {
    source = "../modules/iam/ecs_taskrole"
    policy_name = "AmazonECSTaskRole-Example"
    role_name = "ecaTaskRole_example"
}

# 参照先(resource)
resource "aws_iam_policy" "ecs_task_role_policy" {
    name = var.policy_name
    policy = data.aws_iam_policy_document.ecs_task_role_policy.json
}

# 参照先(variables)
variable "policy_name" {}
variable "role_name" {}

###################################
# ただし、以下の様にvariablesを変更した場合、
# 参照できずエラーになる
###################################
module "sample-code" {
    source = "../modules/iam/ecs_taskrole"
    policy_name = "AmazonECSTaskRole-Example" # policy_nameが存在しないためエラーとなる
    role_name = "ecaTaskRole_example" # role_nameが存在しないためエラーとなる
}

# 参照先(resource)
resource "aws_iam_policy" "ecs_task_role_policy" {
    name = var.policy_name
    policy = data.aws_iam_policy_document.ecs_task_role_policy.json
}

# 参照先(variables)
variable "policy_name_ecs" {}
variable "role_name_ecs" {}
```

そのため、ローカルからmoduleを取得するのではなく、Github Repositoryに存在するmoduleから取得を行ってみる。

# 修正
修正にあたり変更する箇所は1点のみ。
今まではmodule.sourceをローカル指定していたと思うが、ここをGithub Repositoryの対象URLに変更する事で修正が行える。

```
module "sample-code" {
    source = "github.com/example/${Repository名}.git//${moduleディレクトリ名}?ref=${タグ・ブランチ名}"
}
```

ちょっとわかりにくいと思うので、以下で例を挙げる。
例えばGithubのURLが以下の通りで、

```
github.com/kokorozashi/sample-repository
```

ディレクトリ構成が以下の通りだとする。

```
| -- terraform
        | -- applications
        |       | -- service-A
        |       |       | -- ecs.tf
        |       |       | -- iam.tf
        |       |       | -- etc ...
        | -- modules
        |       | -- acm
        |       | -- athena
        |       | -- ecr
        |       | -- ecs
        |       | -- iam
                        | -- ecs_taskrole
                                | -- main.tf
                                | -- variables.tf
```

そして、ブランチ名が "kokorozashi-branch-sample" だった場合、moduleでecs_taskroleを参照するURLは以下の通りとなる。

```
module "sample-code" {
    source = "github.com/kokorozashi/sample-repository.git//terraform/modules/iam/ecs_taskrole?ref=kokorozashi-branch-sample"
}
```

これでローカルから呼び出す事なくGithub Repository上から呼び出すことが可能となった。

また、先ほども言った通り呼び出し方はブランチの他にタグでの呼び出しも可能となっている。

```
# ブランチ呼び出し
source = "github.com/kokorozashi/sample-repository.git//terraform/modules/iam/ecs_taskrole?ref=kokorozashi-branch-sample"

# タグ呼び出し
source = "github.com/kokorozashi/sample-repository.git//terraform/modules/iam/ecs_taskrole?ref=v1.0.0"
```

~~ただし、注意点としてブランチ呼び出しの場合、ブランチの途中に "/" が存在すると、そこで一区切りだと判断され上手く呼び出しができないため、"/" の使用を避けることを推奨する。~~

(10/02追記) 
こちらの事象、スラッシュのエスケープを行えば普通に通過した。
だが、GitBashやWSLでは通過したのだが、なぜかPowerShellのみエスケープやキャレット付与等行っても回避をしてくれない(何故)
そのため、macやLinuxユーザーはそこまで気にすることはなさそう。

```
# 呼び出し不可
source = "github.com/kokorozashi/sample-repository.git//terraform/modules/iam/ecs_taskrole?ref=feature/test-branch"

# 呼び出し可
source = "github.com/kokorozashi/sample-repository.git//terraform/modules/iam/ecs_taskrole?ref=feature-test-branch"
```

Terraformでのモジュール参照方法について

# 挨拶
**みなさん、AWS SAAの資格取得進捗はいかがですか？(挨拶)**
自分の方は新しい資格を取得するためにまた勉強し始めています…

ということは置いといて、今回はアプリケーション統合に関連するサービスを一言で紹介していきたと思います。
前回同様、大まかな説明しかできないので、それ以上に知りたい場合はAWSを覗いたり、他の方のブログを覗いたりしてください。
また、何か内容が異なっていたらコメントを残していただけますと幸いです…

# 内容と投稿順序
AWS SAA-C03試験ガイドで登場する順番ごとに記載を行います。
https://d1.awsstatic.com/ja_JP/training-and-certification/docs-sa-assoc/AWS-Certified-Solutions-Architect-Associate_Exam-Guide.pdf

また、大カテゴリーごとにブログを分けていきます。順番は以下の通りです。
- 分析
- アプリケーション統合(**今回はこれ**)
- コスト管理
- コンピューティング
- コンテナ
- データベース
- デベロッパーツール
- フロントエンドのウェブとモバイル
- 機械学習
- マネジメントとガバナンス
- メディアサービス
- 移行と転送
- ネットワークとコンテンツ配信
- セキュリティ、アイデンティティ、コンプライアンス
- サーバーレス
- ストレージ

# 今回でてくるAWS一般用語説明
AWS何も知らない人向けに今回のサービスで出てくる用語を一覧化しました。
今回はAWS SQSで使用する用語が大半です。

### プロデユーサー
メッセージをSQSへ送信する側。
送信する側の仕切りは特になく、コンポーネントやアプリケーション等なんでも良い。

### コンシューマー
メッセージをSQSから受信する側。
こっちも特に仕切りはない。

### キュー
めちゃくちゃ簡単に言うと、**1列になったメッセージ**のこと。
キューを作成する上限は特になく無限に生成が可能。
ただし、キューへの命名は一意である必要がある。(削除後に再利用可能)

### 標準キュー
無制限で最大のスループットを達成するキュー。
ただし、ベストエフォートのため配信順序は入れ替わる恐れがある

#### ベストエフォート
「確定はできないけど、まぁ自分ができる範囲で頑張ってみるわ」をかっこよく言ったやつ。
1->2->3と送信したら1->2->3と配信してほしい所だが、何らかのアクシデントで送信順序が入れ替わる(1->3->2みたいな)場合もあるのがベストエフォートの特徴。

### FIFOキュー
First In First Outを略してFIFO。その名の通り先入れ先出し方式のキュー。
標準キューとは異なり配信順序は確実に保持される。
ただし上限があり、毎秒300件の送信・受信・削除となっている。(バッチ処理を使用すると毎秒3000件のメッセージ実行を可能とするのは騙してくるポイント)

# AWSサービス一言説明
### Amazon AppFlow
https://aws.amazon.com/jp/appflow/
AWSとSaaSアプリケーション間でデータを簡単かつ安全に転送するための統合サービス。

◆ もっと砕くと
SlackやSalesforceからのデータをS3やRDSといったAWSサービスへと連携してくれるやつ。
設定によってはセキュアな通信も可能。

### AWS AppSync
https://aws.amazon.com/jp/appsync/
サーバーレスなAPIを提供し、モバイルアプリケーションやウェブアプリケーションなどのクライアントからデータを効率的に取得および更新できるサービス。リアルタイムデータ同期、オフライン対応、セキュリティ、認証などの機能を提供する。

◆ もっと砕くと
完全マネージド型サービスでGraphQL API の開発をよしなにしてくれるサービス

◆ 余談
いやGraphQLってなに？ってなった方はこちら↓(実は自分も触ったとこがないのでわかってない)
https://zenn.dev/mn87/articles/725793f9a3c24f

### Amazon EventBridge (Amazon CloudWatch Events)
https://aws.amazon.com/jp/eventbridge/
イベントを使用してアプリケーションコンポーネントを接続するサーバーレスサービス。
異なるソースからのイベントを収集し、ルーティングと処理を実行する。

◆ もっと砕くと
なんらかのタイミングが来たら、なんらかの実行を行うサービス。
ココロザシAWSのEC2自動起動・停止もこれを使って制御をしている。

◆ 余談
CloudWatch Eventsという名称も以前まではあったが、両者が統合して残ったのがEventBridge。
CloudWatch Events自体は今でも触ることはできるが、AWS的にはEventBridgeを触って欲しそうにしてる。

### Amazon MQ
https://aws.amazon.com/jp/amazon-mq/
マネージドメッセージキューサービス。アプリケーション間の通信やメッセージングパターンをサポートする。
Apache ActiveMQやRabbitMQなどのメッセージングブローカーをホスティングする。

◆ もっと砕くと
メッセージの管理や定義を行った後、アプリケーションに接続してメッセージを送信するサービス

### Amazon Simple Notification Service (Amazon SNS)
https://aws.amazon.com/jp/sns/
サーバーレスでアプリケーションへの通知を可能にするフルマネージド型メッセージングサービス。
モバイルプッシュ通知や SMS 送信など、さまざまなメディアに対応した分散型の通知サービスとなっている。

◆ もっと砕くと
手っ取り早くプッシュ型の通知を行えるサービス。EメールのほかSMSやスマホへの通知が可能。
ただし、容量制限があるためEメールで長文コンテンツを届ける用途には不向き。

### Amazon Simple Queue Service (Amazon SQS)
https://aws.amazon.com/jp/sqs/
完全にマネージドされたキューサービスで、分散アプリケーション間でメッセージの受け渡しを行うのに便利。
大量のメッセージを効率的にキューイングすることができ、システム間でメッセージを転送する際の遅延やメッセージの喪失を防ぐことが可能。

◆ もっと砕くと
プロデューサー(送信側)が送信したキューを一時保存するサービス。コンシューマー(受信側)は好きなタイミングでキューを取りにこれるのも便利。

◆ 余談
AWS一般用語説明でも多少は説明したが、SQSなんか用語多すぎやん？って思った人はこちら↓
https://qiita.com/miyuki_samitani/items/e46ef9452fcd73f9d240
https://onetech.jp/blog/what-is-amazon-sqs-15317

### AWS Step Functions
https://aws.amazon.com/jp/step-functions/
分散アプリケーションのワークフローを簡単に定義、実行、および調整できるマネージドサービス。
異なるAWSサービスやカスタムアプリケーションのステップ（タスクまたは処理）を連携し、エラーハンドリングや状態の管理をよしなにしてくれる。

◆ もっと砕くと
複数の工程を手順通りやってくれるサービス。
途中で失敗したらその後の工程は全てキャンセルされるのがネック。(せめて途中からスタートさせてくれ)

AWSのメチャクチャ多いサービスを一言で説明してみる(アプリケーション統合編)

# 概要
AWSを初めて使う人や、久方ぶりに触る人にとって問題となってくること、それは
**アホみたいに多いサービスの量**だと思います。

たしかに、複数のサービスをうまく組み合わせて利用するのがAWSの強みですが、前提としてサービスの内容が分からないと宝の持ち腐れ。
なので、このブログでは**AWS SAAで出題されるサービスを主軸として**各サービスを一言づつ、どの様なことができるかを説明していきます。

正直、大まかな説明しかできないので、それ以上に知りたい場合はAWSを覗いたり、他の方のブログを覗いたりしてください。
また、何か内容が異なっていたらコメントを残していただけますと幸いです…

# 内容と投稿順序
AWS SAA-C03試験ガイドで登場する順番ごとに記載を行います。
https://d1.awsstatic.com/ja_JP/training-and-certification/docs-sa-assoc/AWS-Certified-Solutions-Architect-Associate_Exam-Guide.pdf

また、大カテゴリーごとにブログを分けていきます。順番は以下の通りです。
- 分析
- アプリケーション統合
- コスト管理
- コンピューティング
- コンテナ
- データベース
- デベロッパーツール
- フロントエンドのウェブとモバイル
- 機械学習
- マネジメントとガバナンス
- メディアサービス
- 移行と転送
- ネットワークとコンテンツ配信
- セキュリティ、アイデンティティ、コンプライアンス
- サーバーレス
- ストレージ

# 今回でてくるAWS一般用語説明
AWS何も知らない人向けに今回のサービスで出てくる用語を一覧化しました。
(MapReduceとかHiveとかが気になったら各々で調べてください…)

### マネージド
AWSが運用や管理を担当し、利用ユーザーは運用等の負担を軽減できる状態。つまりは楽。

### ETL
Extract, Transform, Load、日本語では抽出・変換・読み込みのこと。
その名の通り、データを抽出して、変換し、読み込みを行ってくれる。
簡単に言うと、ぐちゃぐちゃだったファイルの中身を必要なものだけ取得し、あいうえお順に並べて、これから使う別のファイルに移し替える(みたいな感じ？)

### ストリーム処理
データを一定の期間留めるなどせず、即座に分析や処理を行う技法。
(データが)きたら即やる戦法

### バッチ処理
データを一定の期間留め、一定の量が溜まったか、時間経過により分析や処理を行う技法。
(データが)きても後でやる戦法

 ### データウェアハウス(DWH)
データの倉庫。
一般的なデータベースと違い、削除や更新と言った出し入れが少ないデータを格納する。
データ分析の際にめっちゃ使う(はず)

# AWSサービス一口説明
### Amazon Athena
https://aws.amazon.com/jp/athena/
サーバーレスなクエリサービスで、S3に保存されたデータをSQLクエリを使用して分析・探索するためのツール。

◆ もっと砕くと
S3に保存されたデータを引っ張ってきてSQLを実行する、DBいらずで楽チン。

### AWS Data Exchange
https://aws.amazon.com/jp/data-exchange/
データプロバイダーとデータコンシューマーの間でデータセットやコンテンツの共有と交換を簡素化するデータ共有プラットフォーム。

◆ もっと砕くと
世界中の金融やメディアといったデータをサブスクして使用できるサービス。

### AWS Data Pipeline
https://aws.amazon.com/jp/datapipeline/
異なるAWSサービス間でデータの移動や変換を自動化するためのウェブサービス。

◆ もっと砕くと
保存先に定期的にアクセス、最低限の加工を行って、AWSサービスに転送するサービス。

### Amazon EMR
https://aws.amazon.com/jp/emr/
ビッグデータ処理のためのマネージドHadoopフレームワーク。
スケーラブルなクラスターを提供し、MapReduce、Spark、Hiveなどの処理フレームワークを使用してデータの分析と処理を効率的に実行する。

◆ もっと砕くと
ビッグデータサイズの大規模なデータ処理を実行する。Glueと迷われがち。

### AWS Glue
https://aws.amazon.com/jp/glue/
マネージドなETL（Extract, Transform, Load）サービスで、データの抽出、変換、読み込みを自動化し、データストア間でのシームレスなデータ移動と変換をサポートする。

◆ もっと砕くと
EC2要らずでデータの抽出・変換・読み込み(ETL)をしてくれる。「ETL処理したいね」って言われたらまずはこのサービスを挙げよう

◆ 余談
SAAの試験ではそんなに事細かく突っついてくる問題は出てこないと思うが、GlueとEMRの違いについては以下の通り。(DASとかなら突っついてくる)
https://dev.classmethod.jp/articles/tsnote-glue-lambda-emr-etl-services-selection/

### Amazon Kinesis
https://aws.amazon.com/jp/kinesis/
リアルタイムデータストリーミングプラットフォームで、大量のストリーミングデータを効率的に収集、処理、分析するためのサービス。データをリアルタイムで取り込み、ストリーム処理やバッチ処理を通じてリアルタイム分析や保管を実行可能。

◆ もっと砕くと
**リアルタイム**でデータ処理をしてくれるサービス。よくGlueと並べて騙してくるが、Glueはリアルタイム処理には向いていないので注意。
SAAでは**リアルタイム処理**と言われたらKinesisのことを指していると覚えよう

◆ 余談
Kinesisの種類は4種類と多いがSAAで出題されてそうなのは**Kinesis Firehose**と**Kinesis Data Stream**の2つ。
そこまで詳しくは出てこないと思うが、知っておいて損はない。(SAPなら確実に突っついてくる)
情報が古いが、違いとしては以下の通り。
https://dev.classmethod.jp/articles/difference-between-kinesis-streams-and-kinesis-firehose/

### AWS Lake Formation
https://aws.amazon.com/jp/lake-formation/
データレイクを構築し、管理するためのサービスで、データの収集、整形、セキュリティ設定を簡素化し、構造化・非構造化データを効果的に統合・分析できる環境を提供するサービス。

◆ もっと砕くと
データレイクを実施する際に利用するであろうサービス(AWS GlueやAmazon Athena等)をAWS側が組み合わせてよしなに構築してくれるサービス。
条件に合致すれば1から10までやってくれるすごいやつ。

### Amazon Managed Streaming for Apache Kafka (Amazon MSK)
https://aws.amazon.com/jp/msk/
Apache Kafkaをマネージドサービスとして提供し、リアルタイムデータストリーミングアプリケーションを構築・実行するためのサービス。高可用性と耐久性を備え、大量のストリームデータを処理・分析が可能。

◆ もっと砕くと
サーバーを気にすることなくKafkaが使える！

### Amazon OpenSearch Service (Amazon Elasticsearch Service)
https://aws.amazon.com/jp/opensearch-service/
オープンソースのElasticsearchとKibanaを提供するマネージドサービスで、データの検索、分析、視覚化を可能にする。高度な検索機能やリアルタイム分析が可能。

◆ もっと砕くと
データ分析や全文検索と言った分析を主としているサービス

◆ 余談
Amazon Elasticsearch ServiceはAmazon OpenSearch Serviceの後継。
問題集やAWS試験の際にAmazon Elasticsearch Serviceが出題されることがあるが、それはAmazon OpenSearch Serviceと捉えて良い。

### Amazon QuickSight
https://aws.amazon.com/jp/quicksight/
マネージドなビジネスインテリジェンス（BI）サービスで、クラウド上でのデータ分析と視覚化を簡素化する。ダッシュボードやレポートを作成することも可能。

◆ もっと砕くと
取り込んだデータを人間がぱっと見でわかりやすい様(グラフや図等)に加工すると言った、BIサービスを主としているサービス

### Amazon Redshift
https://aws.amazon.com/jp/redshift/
マネージドデータウェアハウスサービスで、高速なクエリ処理とスケーラビリティを提供し、大量のデータを効果的に分析するサービス。

◆ もっと砕くと
AWSでデータウェアハウス(DWH)と言ったらこれ。	

AWSのメチャクチャ多いサービスを一言で説明してみる(分析編)

# Terraformに入門した
仕事でAWS構成をTerraformで管理することになった。
今までCloudFormation,CDK,Serverless Frameworkを触ってきたのでキャッチアップは十分できそう。
本記事では一旦最小限の構成でデプロイすることでTerraformの雰囲気を掴む。

# 環境構築
自分は「brew install terraform」で十分だった。

# main.tf
terraformは「main.tf」があればデプロイできる。
```hcl:main.tf
#------------------------------
# Terraform 
#------------------------------
# Terraform自体やプロバイダー(AWS)のバージョン定義
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.6.2"
    }
  }
  required_version = ">=1.5.2"
}

#------------------------------
# Provider
#------------------------------
# プロバイダー(AWS)の詳細設定
provider "aws" {
  region = "ap-northeast-1"
}

#------------------------------
# Resource
#------------------------------
# インフラリソースの定義
resource "aws_s3_bucket" "bucket" {
   bucket = "your-bucket-name" //任意のバケット名
}
```

# terraformのコードを綺麗にフォーマットする
「terraform fmt」でフォーマットできる。
追記：エディタに自動実行させることが可能なため、普段使う機会はなさそう。

# terraformのコードの妥当性を検証する
「terraform validation」でデプロイ可能なコードか検証できる。
Cloudformationの「validate-template」と同じ。

# terraformで変更予定の内容を確認する
「terraform plan」で変更差分が確認できる。
CloudFormationの「変更セット」に相当する。

# terraformを環境に適用する
「terraform apply」でデプロイできる。
もちろんオプションで環境変数を渡せるようだが、今回はしない。

# terraformで管理するリソースを削除する
「terraform destroy」でリソースを削除できる。

# 個人的な感想
## CloudFormationの上位互換。理由は以下。
・HCLが読みやすい。
・各コマンドの実行が高速である。
・コマンド実行結果（変更差分やデプロイ結果）が見やすい。
・CloudFormationの課題から解放される。
	→ 1スタック最大500リソース
	→ 分割単位【ライフサイクル】の設計ミスによる更新不可パラメータ
	→ ネストスタックの変更差分が見れない
	などなど。。。
・やはりAWS以外もコード化できるのは強い。※Datadogとかも書いてみたい。

## 小中規模でAWS CDK、大規模でTerraformを検討する。
Terraformは宣言型で、全リソースの詳細設定を書く必要があるのでしんどそう。
AWS CDKのL2 Constructsの強みはやはり捨てられない。
しかし大規模であればメンテナンス性が重要になってくるため、Terraformの方が良さそう。
今後、CDK for Terraformが両方のいいとこ取りをしてくれると期待している。

# まとめ
今回の入門でTerraformの雰囲気（個人的にCloudFormationの使いやすい版）を掴むことができた。
今後も細かいTerraformの機能や学びを発信していきたい。

AWS CDKユーザーがTerraformに入門してみた。

# 元ネタ
https://aws.amazon.com/blogs/mobile/introducing-merged-apis-on-aws-appsync/

# AWS AppSync
## AppSyncとは
AWSのサーバレスなGraphQLサービスです。構築、管理、監視、セキュリティを容易に実装できます。またDynamoDBやLambda、EventBridgeなどの複数のデータソースとシームレスに統合することが可能です。一般的なHTTP APIもデータソースにできるので、拡張性も備えています。そしてAppSyncは単一の「スキーマ」と「データソース」「リゾルバー」「関数」で構成されます。

## AppSyncの課題
### ①スキーマ変更時にバグが生まれやすい。
複数のマイクロサービスを束ねる単一のAPIエンドポイントとしてAppSyncを利用する場合、複数のチームが単一のスキーマを同時に修正する必要があります。しかし単一のスキーマ内にチームごとの適切なガードレール（アクセス権限）を設定することはできません。つまり「他チームのスキーマ定義を上書きしてしまった。。」という事態が発生する可能性がありました。

### ②肥大化した際のメンテナンス性が悪い。
AppSyncは単一のスキーマで動作します。スキーマが肥大化すると、グラフのバグ調査が困難になります。

# Merge APIs on AWS AppSync
Merge APIsを利用すると、複数のAppSyncのAPIエンドポイントを容易＆安全にマージできます。最大10個のAppSyncエンドポイントをマージ可能で、それぞれ独立したAppSync APIとして、作成、更新、テストができるようになります。
![](https://storage.googleapis.com/zenn-user-upload/cdfbd6c56a31-20230530.png)
引用：https://aws.amazon.com/blogs/mobile/introducing-merged-apis-on-aws-appsync/
※以降、マージ先を「Merged API」、複数のマージ元を「Source API」と呼びます。

## 軽くやってみた。
事前にBlog APIとComment APIを作ってます。
### Merged APIを構築する
①「Create API」を押下します。
![](https://storage.googleapis.com/zenn-user-upload/5728bd5178f1-20230531.png)
②「Merged APIs」を選択して、「Next」を押下します。
![](https://storage.googleapis.com/zenn-user-upload/9e5b5fea6a63-20230531.png)
③API名を入力後、「Next」を押下します。
![](https://storage.googleapis.com/zenn-user-upload/16045058908b-20230531.png)
④「Add Source APIs」を押下するとモーダルが出てきます。
マージするAPIを選択して追加後、「Next」を押下します。
![](https://storage.googleapis.com/zenn-user-upload/4b0a2405ccfd-20230531.png)
⑤認証方式を選択できます。検証なので、API Keyのまま「Next」を押下します。
![](https://storage.googleapis.com/zenn-user-upload/38a7cda99307-20230531.png)
⑥最終確認ができたら、「Create API」を押下します。
![](https://storage.googleapis.com/zenn-user-upload/601d43ba534d-20230531.png)
⑦API一覧画面で作成されていればOKです。
![](https://storage.googleapis.com/zenn-user-upload/ff289fe257ed-20230531.png)

### Merged APIでクエリを実行してみる。
Blog API(Source)のクエリがちゃんと実行できています！🎉
![](https://storage.googleapis.com/zenn-user-upload/79743785f5ce-20230531.png)

## 新スキーマディレクティブ
Merged APIのスキーマで各Source APIの定義の競合が発生した場合、新しいディレクティブを利用することで解消することができます。
**@canonical**
Source API間で競合するタイプやフィールドが存在する場合、このディレクティブが付与されている方が優先されます。
**@hidden**
Merged APIにマージしたくない操作や型がある場合、このディレクティブを付与すると回避できます。
**@renamed**
Source API間で競合するタイプやフィールドが存在する場合、このディレクティブを使用することで名前をMerged API上で変更し、競合を解決できます。

## Auto Merge
Merged APIには各Source APIが更新される度に、変更を検知して自動更新するオプションがあります。デフォルト設定は手動更新です。

# 他のアプローチとの比較
Merged APIはSource APIにAppSyncのみサポートしています。Apollo等で構築されたAPIと結合する必要がある場合は、run timeアプローチを利用しましょう。
## build time アプローチ
AppSyncのMerged APIはこのアプローチを採用しています。
各Source APIを別のMerged APIに結合して利用する手法です。
リクエストはクライアント → Merged API → データソースという流れになります。
Merged APIとSource APIの両方を単一のリクエストが通過することはあり得ません。
![](https://storage.googleapis.com/zenn-user-upload/f48f132069fe-20230531.png)

## run time アプローチ
各SubGraphの前段にルーティング用のAPIを用意する手法です。
リクエストはクライアント → Router → SubGraph → データソースという流れになります。
クライアントは簡易的なリクエストして、RouterがSubGraphに対して必要なリクエストを構築します。
![](https://storage.googleapis.com/zenn-user-upload/9616c9b24e09-20230531.png)

# まとめ
Merged APIsによって、マイクロサービスの運用がかなり楽になると思います。
本記事の元ネタになっているAWSブログではより具体的なデモが記載されていますので、興味がある方は是非ご覧になってみてください。
ではまた👋

【新機能】AWS AppSyncのMerged APIs を理解する。

# はじめに
Next.jsでSSGからSSRへの変更を行なったので違いを纏めておきます。

# ISR、SSRとは
## ISR
Incremental Static Regenerationの略称。
ビルド時にサーバー側でAPIからのデータ取得とHTMLの生成を実施し、クライアント側からリクエストされた際に事前に生成しておいたHTMLを渡すアーキテクチャー。一定時間ごとにバックグラウンドでデータの再取得およびページの再レンダリングを行い、HTML を再生成する。

## SSR
Server Side Renderingの略称。
ページ遷移のたびサーバーにリクエストが走り、サーバー側でAPIと連携され生成されたHTMLをブラウザに返すアーキテクチャー。


# Next.jsにおける実装方法
## SSG
getStaticPaths及びgetStaticPropsを使用して実装する

```tax
import { GetStaticProps } from "next";
import { Params } from "next/dist/shared/lib/router/utils/route-matcher";
import { ParsedUrlQuery } from "querystring";

export const getStaticPaths = async () => {
 // パスの取得
 const idList = await getIdsAPI();
 const paths = idList?.map((id) => {
 return {
 params: {
 id: id,
 },
 };
 });
 return {
 paths,
 fallback: true,
 };
};

export const getStaticProps: GetStaticProps<
 Params,
 ParsedUrlQuery
> = async ({ params }) => {
 // パスに対応するコンテンツを取得
 const res = await getContentAPI(params?.id || "");
 if (res instanceof Error) {
 return {
 props: {
 isError: true,
 },
 revalidate: 5,
 };
 }
 return {
 props: {
 res.contest,
 isError: false,
 },
 revalidate: 5,
 };
};
```

### 何をしているか 
- getStaticPaths：ビルド時にレンダリングする必要のあるパスリストの生成
- fallback：リストが空の場合の挙動をクライアント側で作成するために設定
- getStaticProps：ビルド時に静的なファイルを生成し、ページコンポーネントで使用する値を取得
- isError：コンテンツ取得時にエラーが発生したかどうかを確認するために設定
- revalidate：ページ情報の再取得時間


## SSR
getServerSidePropsを使用して実装する

```tax
import {GetServerSideProps} from "next";
import { authOptions } from '@/pages/api/auth/[...nextauth]'
import { getServerSession } from "next-auth/next"
import { ParsedUrlQuery } from "querystring";

export const getServerSideProps: GetServerSideProps = async context => {
 const session = await getServerSession(context.req, context.res, authOptions);
 const { id } = context.params as ParsedUrlQuery;

 // コンテンツの取得
 const res = await getContentAPI( id );
 if (res instanceof Error) {
 return {
 props: {
 isError: true,
 },
 };
 }

 return {
 props: {
 res.content,
 isError: false,
 },
 };
};
```

### 何をしているか 
- getServerSideProps：ページコンポーネントで必要なデータを取得
- getStaticPaths：ビルド時にレンダリングする必要のあるパスリストの生成
- getServerSession：セッションの取得

# まとめ
ページ生成を別の方法にするのは難しいものだと思っていましたが、やり方さえ分かっていればそう難しい話ではなかったです。覚えておこうと思います。

ISRとSSR

現場でこのサービスを使うことになったので、簡単に紹介します。

# AWS Backupとは
S3やEC2やDynamoDBなどのバックアップを簡単に取ることを実現できるサービスです。
バックアップを一元的に、一括で管理することに長けています。

# バックアップボールトとバックアッププラン
AWS Backupではバックアップボールトとバックアッププランを組み合わせてバックアップを取っていきます。
- バックアップボールト＝バックアップを取ったものを置く倉庫のようなもの
- バックアッププラン＝どのように、いつバックアップを取るかの計画

というように理解するとわかりやすいと思います。

![Backup VaultとBackup Plan](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/1fbe58db-a8d6-401e-928d-7a684e752437.webp)

# EC2のバックアップをとってみる
実際にEC2のバックアップを取ってみます。やりたいことは以下のような感じで、EC2を毎時Tokyo regionからOsaka regionへバックアップしていきます。
![](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/d281deb4-a69f-4ea7-804e-5f678e0c78bc.webp)

まず、AWS Backupの画面を開きます。
![](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/667f8d3d-3730-4529-b5a2-0f24400f567a.webp)
ボールトを先に作る必要があるので、**早速リージョンを大阪に切り替えて (大事)**、ボールトを作成します。
![](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/b320cbce-4f96-44c1-b237-de1f01a407a9.webp)
左のメニューからバックアップボールトを作っていきます。
![](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/074ad55e-4296-4a74-a9e7-651743a83729.webp)
こんな感じで名前とKMSキーを指定するだけでバックアップボールトが作れます。今回は気軽に行きたいのでAWSマネージド型のキーを使います。
![](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/8d9637af-a5a1-442a-9f79-ebc809af8d09.webp)
正常に作成されました。同じ要領で東京リージョンにもボールトを作成していきます。
![](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/87c5b60d-675c-4fd6-9d5b-163f8bb72a59.webp)
通知にあるようにプランが必要なので、**東京リージョンに戻り**作成していきます。
左のメニューからバックアッププランを選択し、作成していきます。今回は詳細にオプションを確認しながら作るので、「新しいプランを作成」していきます。
![](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/7f0b7dfb-491c-4ca3-b37b-f7e748fdafab.webp)
ここでバックアップボールト、頻度、コールドストレージへの移行を選択できます。
![](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/3deca86f-8b1f-4c2b-b588-4069cb0a8df1.webp)
デフォではクロスリージョンレプリケーションはオフになっていますが、今回は大阪にバックアップしたいので、以下のように選択していきます。
先程大阪に作ったボールトに格納します。その後、プランを作成を押してください。
![](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/d678f0d9-b896-47d7-af3b-107e5e3e161f.webp)
次に「どのリソースに対して」先程の設定でバックアップするかを設定します。
![](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/dbcbd809-1070-4eac-aa9f-d2e9c35b5611.webp)
今回は特定のEC2をバックアップしたいので、以下のように選択していきます。
ここで、そのアカウントの全てのEC2をバックアップするなど選べるので便利ですね（コストには注意）。
これでバックアッププランは完成です。作成していきましょう。
![](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/47f89372-2451-4a9a-81de-22e72a2399c9.webp)
作成されるとこんな感じで出来上がっていると思います。
![](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/f11d9626-d801-4c10-afb8-9922a1eec9db.webp)
ある程度待つと大阪のボールトにバックアップが溜まっていきます。

※このまま放置するとコストがかさむので1日程度放置したらプランを削除しましょう。不要ならバックアップの削除も。


# コスト感
所感をまとめました。
- 大体のサービスが0.05 ~ 0.10USD/GB。ということは約50 ~ 100USD/TB。
- アカウント全てのEBSのバックアップを取るとか、全てのS3のバックアップを取るなどするとすぐに数百ドル～は請求されそうなイメージ。
- というようなコスト感なので全バックアップは予算にかなり余裕がないと使いづらい。
- クロスリージョンでバックアップを取るとより高い。すなわち転送量が高い。0.09USD/GBなのでざっくり倍かかる。
- 当たり前だが、本当に必要なリソースだけ、死んだらクリティカルに影響するリソースに絞ってこのサービスを活用したい。
- 以下の表のように、各サービスが標準的に備えるバックアップの仕組みとコストの違いがある。(バックアップとレプリケーションは本質的には違うが、一旦代用として考える) 用途に応じて使い分ける。

| サービス | 代用サービス | AWS Backupの料金 | 代用サービスの料金 |
| :---: | :---: | :---: | :---: |
| DynamoDB | ポイントインタイムリカバリ | 0.114 | 0.200 |
| S3 | レプリケーション | 0.060 | 0.015+α† |
| EBS (EC2) | スナップショット | 0.050 | 0.050 |
| EFS | 自動バックアップ†† | 0.060 | 0.060 |

† オブジェクト数が多ければ多いほどαは高い。
†† EFSの自動バックアップは裏でAWS Backupを使っているので実質同等。

# まとめ
バックアップを一元的に管理したいなら便利なサービスだと思いました！

AWS Backupを使ってみる

現場の業務でKMSの設計を急に一任されたので、その時考えてたことです。

# そもそもKMSとは？
ストレージ上のデータや機密情報を暗号化するために便利なサービスです。セキュアに情報を扱うべきときには必ず使うサービスだと思います。主にはS3のデータを暗号化したり、Lambdaの環境変数 (従量課金されちゃうAPIのKEYとか)を暗号化するために使われることが多いです。


![KMS概要](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/7b013673-65d7-406f-bcf5-52870702131e.webp)

# 現場での要件
- これから開発環境の環境構築を行う
- KMSについては何も決めてないので、いい感じに設計してほしい（半分投げやり）
- KMSを使うサービスはストレージ系、セキュリティ系含む複数
- KMSがないと設定できないサービスもあるので、なるはやで考えてほしい（設計〜実装まで3日以内くらい）

# 実際の設計
## AWS マネージド型か、カスタマーマネージド型か
AWS マネージド型とカスタマーマネージド型の比較は[公式ドキュメント](https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/concepts.html#symmetric-cmks)が最も信頼できるのでそちらに譲りますが、現場での視点では以下のメリデメがありました。


| キーの種類 | メリット | デメリット |
| :---: | :---: | :---: |
| AWS マネージド型 | 設定がかなり楽 | 個別にポリシーの設定ができない |
| カスタマーマネージド型 | 運用が柔軟にできる | 事前に設計する必要がある |

AWS マネージド型のメリットの「設定がかなり楽」の真の意味は、「他のサービスからKMSを設定するときに、KMSを事前に作成する必要がなく、勝手に作ってくれるので楽」という意味です。今回の開発環境構築では手動で複数人で同時に構築していくスタイルだったので、時間が限られている中このメリットは正直かなり大きかったです。

ですが、調査をしていくとデメリットにあるように運用の柔軟性がほぼ全て失われてしまうことが判明しました。今後想定外にポリシーの変更が必要になった場合、もう一度サービスとKMSを作り直す事態を避けたいと判断し、結局今回はカスタマーマネージド型を選択することとしました。
**※実際この後VPCフローログの設定の際に出力先S3をKMSで暗号化していた場合、追加のKMSのポリシー設定が必要になりました。**

## KMSを1つにするか、複数にするか
次に、複数サービスで使うKMSを1つにまとめるか、サービスごとに分ける形で複数にするかで迷いました。こちらもメリデメを。
  
| キー数 | メリット | デメリット |
| :---: | :---: | :---: |
| 1つ | コストが安い | キーポリシーの管理が煩雑化する |
| 複数 | 運用が柔軟にできる | キーの分コストがかさむ |

まずKMSのコストですが、カスタマーマネージド型の場合、置いとくだけで基本的に1個あたり$1/月です。今回の予算は万ドル~/月のスケールだったので、コストについてのメリデメは軽微だったので無視しました。となると数ドル節約して運用を煩雑化させるかどうかというレベル感の話になるので、サービスごとに複数に分ける形を採用しました。

複数サービスでKMSを使うのにキーを1つにまとめると将来的にキーポリシーがめちゃくちゃ長くなることと、キーのユーザーに対する権限の付与をサービスごとに分けることができなくなるため、運用がかなり窮屈になります。極限までコストを節約したいとか、ユーザーが自分しかいないとか、そういう特殊な状況下では逆に1つにまとめるでもいいと思います。

## KMS自体の設定はどうするか
これは基本的にデフォルトで作られる「対称暗号化 KMS キー」で問題ないと判断しました。
キーの原理などを軽く調査したりしましたが、詳細に検討する時間が取れなかったことと開発環境だしとりあえず暗号化されていれば問題ないと判断したためです。この辺りは本番環境の環境構築までに要検討としました。

# まとめ
- 基本的にKMSはサービスごとに分けたほうがいい
- 後で運用しないなら作るのが楽だしAWSマネージド型で！
- しっかり運用するならカスタマーマネージド型で！

# 最後に
KMSを設計したことない人、そもそもKMSを知らない人でもこんな感じで考えて設計すればいいんだなという参考になればと思います！	

KMSの設計・メリデメ比較

# はじめに

ボタンにアニメーションを付けるためにLottieを使用したのでどういうものかを纏めました。

# Lottieとは
オープンソースのアニメーションライブラリ。
JSONベースのアニメーションファイルで、使用すると静止画と同じようにアニメーションを使用することができる。

# アニメーションボタンの作成方法
## 準備
①アニメーションファイルを用意
　Lottie公式サイトで配布されている、使用したいアニメーションをダウンロードする。
　ダウンロード時にサイズ調整できるので予めサイズも調整しておくと後が楽。
　新規で作成する方法もあるが、今回は既存のハートアニメーショーンを使用したので割愛。
　サイズを後から調整する場合は、マイページから可能。

②アプリケーションにreact-lottieをインストールする
```yarn
yarn add react-lottie
```

## 実際の使用方法
アニメーションファイルを「Heart.json」とすると、下記のように使用できます。
```tax
import React from "react";
import Lottie from "react-lottie";
import animationData from "./Heart.json";

const ButtonComponent = () => {
 const defaultOptions = {
 loop: true,
 autoplay: true,
 animationData
 };

 return (
 <button>
 <Lottie options={defaultOptions} height={250} width={250} />
 </button>
 );
};

export default ButtonComponent;
```


## Lottieで使用できるプロパティ例
- loop:ループ
- autoplay:自動再生
- animationData:アニメーションのデータファイル


# まとめ
アニメーションを埋め込むのはかなり難易度の高いものだと思い込んでいたのですが、簡単にアニメーションを設定できました。

# 参考
[Lottie公式サイト](https://lottiefiles.com/jp)

Lottieを使用したアニメーションボタン作成

# はじめに
RedisにC++アプリケーションで外部のRedisサーバーに接続する方法を記載します。

# hiredisのビルド
C++でRedisに接続するためにhiredisというライブラリを使用します。
デフォルトでTLSに対応していないため、再ビルドします。

MakeFileの修正
```
USE_SSL=1
```

CMakeListの修正
```
ENABLE_SSL ON
```

VisualStudioでコマンドプロンプトを開きcmakeでビルドします。
```
$ cmake -G "Visual Studio 17 2022" .
$ cmake --build .
```

# C++ソースコード
事前に作成した証明書ファイルと鍵ファイルをクライアントに転送しておき、任意のディレクトリに配置します。

プロパティで下記の設定をします。
・hiredis.h, hiredis_ssl.hをインクルードする
・hiredis.lib, hiredis_ssl.ibをリンカーに追加する


~~~C++:redis_tls_test.cpp
#include "hiredis.h"
#include "hiredis_ssl.h"
#include "ssl.h"

int main()
{
    redisContext* con;
    redisSSLContext* ssl_context;
    redisSSLContextError ssl_error = REDIS_SSL_CTX_NONE;
    redisReply* rep;

    // 初期処理
    redisInitOpenSSL();

    // 接続先情報
    ssl_context = redisCreateSSLContext("証明書ファイルの絶対パス", NULL, "証明書ファイルの絶対パス","鍵ファイルの絶対パス", "接続先IPアドレス", &ssl_error);

    if(ssl_context = NULL || ssl_error != REDIS_SSL_CTX_NONE) {
        // エラー処理
    }

    // 接続
    con = redisConnect("接続先IPアドレス", 接続先ポート);
    if(!con || con->err){
        // エラー処理
    }

    if(redisInitiateSSLWithContext(con, ssl_context) != REDIS_OK) {
        // エラー処理
    }

    // SETコマンド
    rep = (redisReply*)redisCommand(con, "SET Key value");
    if(!rep){
       // エラー処理
    }

    // GETコマンド
    rep = (redisReply*)redisCommand(con, "GET Key");
    if(!rep){
       // エラー処理
    }
    if(rep->type != REDIS_REPLY_ERROR){
        printf("keyの値 = %s, rep->str);
    }

    // 後処理
    freeReplyObject(rep);
    redisFree(con);

    return 0;
}
~~~

# おわりに
TLSを使わない場合は、サーバ側含めてTLSのために行った内容を抜かせば非TLSで接続できます。

RedisのACL機能も使ったので気が向いたら書くかも。
		

RedisのTLS接続(クライアント側)

# はじめに
業務でRedisのTLS接続をした時に苦戦したので書いてみます。

Redis：Linux
クライアント：Windows
想定です。

#  OpenSSLインストール
RedisはデフォルトではTLSに対応していないため、OpenSSLをインストールした状態でとRedisの再ビルドが必要になります。

まずはOpenSSLをインストールします。
バージョンは古すぎなければ大丈夫なので1.1.1でやりました。

普通にインストールすれば大丈夫ですが、次章のビルドでエラーが出た場合は、
libssl.soとlibcrypto.soにリンクを貼る必要があります。

# Redisの再ビルド
下記コマンドを実行してRedisを再ビルドします。

```
$ make BUILD_TLS=yes
```

ビルドエラーが出た場合、下記コマンドを実行します。

```
$ make MALLOC=libc
$ make MALLOC=jemalloc
```

# 証明書作成
TLS接続に使用する証明書を作成します。

証明書のCNにIPアドレスを指定する場合、SAN対応の証明書が必要になるので、今回はその方法を記載します。

証明書を配置するディレクトリに移動し下記のテキストファイルを用意します。
```san.txt
subjectAltName = DNS.*.example.com,IP:127.XX.XX.XX
```
IPだけでも大丈夫です。


下記コマンドを実行します。
```
$ openssl genrsa -out server.key 2048
$ openssl req -out server.csr
$ openssl x509 -req -days 3650 -signkey server.key -in server.csr -out server.crt -extfile san.txt
```

# conf修正
TLSの設定をするために、redis.confを修正します。

```
# 195行目　非TLSポートの無効化
port 0
# 196行目　TLS使用ポート
tls-port 6379


# 202行目、203行目　証明書ファイル、鍵ファイルの指定
tls-cert-file /etc/~/server.crt
tls-key-file /etc/~/server.key

# 238行目　証明書ディレクトリ指定
tls-ca-cert-dir /etc/~

# 248行目　相互TLS無効化
tls-auth-client no
```

設定後にRedisを再起動します。

# ローカルからのTLS接続確認
下記コマンドで接続確認します。

```
$ redis-cli --tls --cert 証明書ファイル --key 鍵ファイル --cacert 証明書ファイル
$ set key value
$ get key
```

# おわりに
これでRedisをTLSに対応しました。
次回はクライアントからC++ のプログラムからRedisに接続する方法を記載します。



RedisのTLS接続(サーバー側)

# はじめに
[【Next.js+microCMS】１．microCMSとNext.jsの連携](https://www.kokosyna.com/posts/ad9c4b79-1f48-48e5-9aba-80d4f73a91e1)
今回は↑の記事で一覧表示したページをページネーションできるページに作り替えます。
1ページ5件の表示にします。

# ページネーションについて
Next.jsを使用してページネーションを行う場合はprerendering時に下記のメソッドを使用します。
- getStaticPaths
> ビルド時の静的ページ作成で必要となるページ数を取得する。getStaticProps側で参照できる。
> 今回は{paths: {params: {pageNum:string}}[], fallback: boolean}の形式でreturnする。
> ※Next.jsの仕様でpathsには必ずparamsキーを含む必要がある。
- getStaticProps
> getStaticPathsから取得したparamsを基に静的ページを作成する。


# 実装
## ロジック部分
- pagenationFunc.ts
>- getPaths:{params: {pageNum:string}}[]形式のデータをgetStaticPathsにreturnする。
>- getPageList:microCMSから取得した1ページ分(5件)のデータとデータ総件数をgetStaticPropsにreturnする。
```typescript:/lib/data-list/page/pagenationFunc.ts
import { cmsClient } from "@/lib/common/cmsClient";
import { CMS_TESTAPI_ENDPOINT } from "@/lib/common/constants";

// getStaticPathsのpaths取得
export const getPaths = async () => {
 const result = await cmsClient.get({
 endpoint: CMS_TESTAPI_ENDPOINT,
 queries: {
 fields: [],
 offset: 0,
 limit: 0,
 },
 });
 const paths = editPagePaths(result.totalCount);

 return paths;
};

// microCMSのデータ件数を基に必要なページ数を判定してpathsの形式に修正
const editPagePaths = (dataCount: number) => {
 const pageCount = Math.ceil(dataCount / 5);
 // getStaticPathsのpaths用に{params:{pageNum:string}}[]に編集
 const paths = [...Array(pageCount)].map((_, index) => {
 return { params: { pageNum: (index + 1).toString() } };
 });
 return paths;
};

// pageData一覧取得
export const getPageList = async (pageNum: number) => {
 // 取得開始件数の判定（1ページ目だったら0件目から、それ以外は(page数-1) * 5件目から）
 const offset = pageNum === 1 ? 0 : (pageNum - 1) * 5;
 const result = await cmsClient.get({
 endpoint: CMS_TESTAPI_ENDPOINT,
 queries: {
 fields: ["id", "name", "age"],
 offset: offset,
 // 1ページ5件の制御
 limit: 5,
 },
 });

 return {
 totalCount: result.totalCount,
 cmsDataList: result.contents,
 };
};

```

## 画面表示部分
- index.tsx
> ホーム画面から一覧ページ(1ページ目)へ遷移するリンクを配置
```typescript:/pages/index.tsx
import { Box, Typography } from "@mui/material";
import Link from "next/link";

export default function Home() {
 return (
 <Box
 sx={{
 display: "flex",
 flexFlow: "column",
 alignItems: "center",
 justifyContent: "center",
 height: "100%",
 }}
 >
 <Typography variant="h3">リンク一覧</Typography>
 <Link
 href="/data-list/page/1"
 style={{
 color: "#337ab7",
 }}
 >
 ページネーションの確認
 </Link>
 </Box>
 );
}
```
- [pageNum].tsx
> getStaticPathsとgetStaticPropsを使用して、必要なページをビルド時に作成

```typescript:/pages/data-list/page/[pageNum].tsx
import { CmsDataListInfo, CmsData } from "@/type/data-list/dataListType";
import { getPaths, getPageList } from "@/lib/data-list/page/pagenationFunc";
import { Box } from "@mui/material";
import ListView from "@/components/data-list/ListView";
import Pagenation from "@/components/data-list/Pagenation";

// type
type Props = {
 pages: number[];
 cmsDataList: CmsData[];
};

// function
const editPages = (totalCount: number) => {
 const pageCount = Math.ceil(totalCount / 5);
 const pages = [...Array(pageCount)].map((_, index) => {
 return index + 1;
 });
 return pages;
};

// preRendering
export async function getStaticPaths() {
 const paths = await getPaths();

 return {
 paths,
 fallback: false,
 };
}

export async function getStaticProps(context: any) {
 console.log(context);
 const cmsDataListInfo: CmsDataListInfo = await getPageList(
 parseInt(context.params.pageNum)
 );
 const pages = editPages(cmsDataListInfo.totalCount);
 const cmsDataList = cmsDataListInfo.cmsDataList;

 return {
 props: {
 pages,
 cmsDataList,
 },
 };
}

const PageList = (props: Props) => {
 const { pages, cmsDataList } = { ...props };
 return (
 <Box
 sx={{
 display: "flex",
 flexFlow: "column",
 alignItems: "center",
 justifyContent: "center",
 height: "100%",
 }}
 >
 <ListView cmsDataList={cmsDataList} />
 <Pagenation pages={pages} />
 </Box>
 );
};

export default PageList;
```
- ListView.tsx
> microCMSから取得したデータのリストを受け取って表示するコンポーネント

```typescript:/components/data-list/ListView.tsx
import { CmsData } from "@/type/data-list/dataListType";
import { Card } from "@mui/material";

type Props = {
 cmsDataList: CmsData[];
};

const ListView = (props: Props) => {
 const { cmsDataList } = { ...props };
 return (
 <>
 {cmsDataList.map((cmsData: CmsData, key: number) => {
 return (
 <Card key={key} sx={{ width: "80%", margin: "2%" }}>
 {`コンテンツID：${cmsData.id}`}
 {`名前：${cmsData.name}`}
 {`年齢：${cmsData.age}`}
 </Card>
 );
 })}
 </>
 );
};

export default ListView;
```
- Pagenation.tsx
> microCMSから取得したデータ総件数を基に作成したページ配列を受け取ってページネーションのボタン部分を表示するコンポーネント

```typescript:/components/data-list/Pagenation.tsx
import { Box } from "@mui/material";
import Link from "next/link";

type Props = {
 pages: number[];
};
const Pagenation = (props: Props) => {
 const { pages } = { ...props };
 return (
 <Box
 sx={{
 display: "flex",
 flexFlow: "row",
 alignItems: "center",
 justifyContent: "center",
 gap: 4,
 }}
 >
 {pages.map((pageNum) => {
 return (
 <Link key={pageNum} href={`/data-list/page/${pageNum}`}>
 <Box
 sx={{
 border: "solid",
 width: 30,
 height: 30,
 textAlign: "center",
 backgroundColor: "#b0c4de",
 color: "white",
 "&:hover": {
 backgroundColor: "#0000ff",
 borderColor: "black",
 },
 }}
 >
 {pageNum}
 </Box>
 </Link>
 );
 })}
 </Box>
 );
};

export default Pagenation;
```

# 実行結果
- ホーム画面から[ページネーションの確認]をクリック

![](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/58d22fc7-4da8-4300-9894-a3d8fc8d98f7.webp)

- 一覧表示（1ページ目）から2ページ目のボタンをクリック

![](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/5c51c2a7-85a2-4e93-9d34-ea3a41d4b2d7.webp)
![](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/5a0895a9-e770-42f3-8e51-624666ee7940.webp)

動作確認してみたところ、問題なくページネーションができました。

# 今後の投稿予定
今後は下記の記事を投稿していく予定です。
- 【Next.js+microCMS】３．検索・更新・削除
- 【Next.js+microCMS】４．排他制御
- 【Next.js+microCMS】５．拡張フィールド

【Next.js+microCMS】２．ページネーション

# はじめに
私は現在Next.jsの自己学習を行っており、バックエンドのAPIを簡単に作成できるmicroCMSを使用して学習を進めております。
Next.js・microCMS共に初心者なのですが、学習のアウトプットをしていきたいと思います。

# microCMSとは
https://microcms.io/
microCMSはAPIベースの日本製ヘッドレスCMSです。
ざっくりまとめるとヘッド（フロントエンド）のないCMS（コンテンツ管理システム）のことで、管理画面でポチポチするだけでAPIが作成できるとても便利なサービスです。

# microCMSでAPIを作成してみよう
今回は「名前(name)」,「年齢(age)」のフィールドを持つテストAPIを作成しました。
![](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/d2299760-ac47-463b-85a2-e30b8c5a4ac8.webp)

# Next.jsでmicroCMSのデータを取得してみよう
## 事前準備
まずはmicroCMS公式で提供している「microcms-js-sdk」をインストールします。
```
npm install microcms-js-sdk
```
## サンプルコード
+ cmsClient.ts：microCMS接続用のclient作成
```typescript:/lib/common/cmsClient.ts
import { createClient } from "microcms-js-sdk";

// 環境変数の取得
const CMS_SERVICE_DOMAIN = process.env.CMS_SERVICE_DOMAIN
 ? process.env.CMS_SERVICE_DOMAIN
 : "";
const CMS_API_KEY = process.env.CMS_API_KEY ? process.env.CMS_API_KEY : "";

// microCMSClientの作成
export const cmsClient = createClient({
 serviceDomain: CMS_SERVICE_DOMAIN,
 apiKey: CMS_API_KEY,
});
```
+ dataListFunc.ts：microCMSからデータ取得
```typescript:/lib/data-list/dataListFunc.ts
import { cmsClient } from "../common/cmsClient";

// 環境変数の取得
const CMS_TESTAPI_ENDPOINT = process.env.CMS_TESTAPI_ENDPOINT
 ? process.env.CMS_TESTAPI_ENDPOINT
 : "";

// data一覧取得
export const getList = async () => {
 const result = await cmsClient.get({
 endpoint: CMS_TESTAPI_ENDPOINT,
 queries: {
 fields: ["id", "name", "age"],
 },
 });

 console.log(result);

 return result.contents;
};
```
+ index.tsx：microCMSから取得したデータを画面表示
```typescript:/pages/data-list/index.tsx
import { getList } from "@/lib/data-list/dataListFunc";
import React from "react";
import { Box, Card } from "@mui/material";

// type
type CmsData = {
 id: string;
 name: string;
 age: number;
};

type Props = {
 cmsDataList: CmsData[];
};

// preRendering
export async function getStaticProps() {
 const cmsDataList: CmsData[] = await getList();
 return {
 props: {
 cmsDataList,
 },
 };
}

const DataList = (props: Props) => {
 const { cmsDataList } = { ...props };
 return (
 <Box
 sx={{
 height: "100vh",
 display: "flex",
 flexFlow: "column",
 alignItems: "center",
 justifyContent: "center",
 }}
 >
 {cmsDataList.map((cmsData: CmsData, key: number) => {
 return (
 <Card key={key} sx={{ width: "80%", margin: "2%" }}>
 {`コンテンツID：${cmsData.id}`}
 {`名前：${cmsData.name}`}
 {`年齢：${cmsData.age}`}
 </Card>
 );
 })}
 </Box>
 );
};

export default DataList;
```
## 実行結果
microCMSからAPI経由で取得したデータを画面表示することができました！
![](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/4fa4daff-718f-4c0a-bbba-6f7dc715f9fe.webp)

# 今後の投稿予定
今後は下記の記事を投稿していく予定です。
+ 【Next.js+microCMS】２．ページネーション
+ 【Next.js+microCMS】３．検索・更新・削除
+ 【Next.js+microCMS】４．排他制御
+ 【Next.js+microCMS】５．拡張フィールド

【Next.js+microCMS】１．microCMSとNext.jsの連携

# 最初に

![](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/150d9da3-d1cb-4209-8dc2-91a33ca1aedf.webp)

フロントエンドでフローチャートやUMLに類する図形を描きたい時があります。
例えばデータの関連性を図として示して分かりやすくしたり、逆にデータ同士をどう紐づけるかをGUIで指定させたいといった状況です。

その際に便利な[React Flow](https://reactflow.dev/)を紹介します。
実際に私もこれを使用し、データを含めて事業戦略を検討できるWebアプリを作成していました。

React Flowはその名の通り、Reactを使用してフローチャートのようなノード、エッジを描画するライブラリです。
逆にユーザーが操作して、直感的にノードとノードを接続するということも可能です。
動作サンプルとしては[公式トップページ](https://reactflow.dev)に表示されているものが分かりやすいと思うのでそちらに譲ります。触って動かせます。

今回はこのライブラリについて、主にエンジニア視点で特徴をいくつか挙げていこうと思います。

# 特徴

### コンポーネント一つを置くだけで利用できる。

ただノードとエッジを描画するだけなら以下の記述で完了します。
(nodesとedgesに描画したいデータを入れる必要はある。)
一般的なコンポーネントと同様に<ReactFlow>コンポーネントを置くだけで済むので、利用も撤去も非常に簡単です。

```
<ReactFlow
 nodes={nodes}
 edges={edges}
>
</ReactFlow>
```

ミニマップや拡大縮小ボタンもコンポーネント化されているため、以下のように<ReactFlow>コンポーネント内に設置するだけでそれらの利用も可能です。

```
<ReactFlow>
 <MiniMap />
 <Controls />
</ReactFlow>
```

### エッジやノードのデータ表現が簡潔。

例えばシンプルなエッジやノードは以下の用になります。
しっかりと整理されておりデータの用途なども想像しやすいため、React Flow初心者でも非常に理解しやすくなっています。

```
nodes = {
 id: "n1", // ノードを特定するID
 position: { x: 0, y: 0 }, // ノードの表示位置
 data: { // ノードの内容について
 label: <>example</>, // 表示テキスト
 },
}

edge = {
 id: "e1", // エッジを特定するID
 source: "n1", // 始点ノード
 sourceHandle: "right", // 始点ノードのどのポイントに接続するか
 target: "n2", // 終点ノード
 targetHandle: "left", // 終点ノードのどのポイントに接続するか
 },
```

### カスタムノードによりフローチャート以外にも利用可能。

これはプログラミングとは少し別方向のメリットですが、ノードの形状やスタイル、接続点などは自由に編集可能なため応用範囲が広く、1つのライブラリを覚えるだけで複数種類のUIを作成できます。

カスタムノードも下記のようにJSXで自由にデザインでき、接続点などの設定も簡潔です。

```
custom = (
 <>
 <>{data.label}</>
 <Handle id="left" type="target" position={Position.Left} />
 <Handle id="top" type="source" position={Position.Top} />
 </>
)
```

ただ現時点の私では、始点にも終点にもできる接続点の設定の可否がわからないため、UMLのような図形を全て賄えるかは分かっていません…。
方法があればどなたか教えて頂けると幸いです。

### イベント等もしっかり用意されている。

もちろん、ノードやエッジの変化、パネルのクリックなど、想定されるイベントはきちんと用意されています。

```
<ReactFlow
 onNodesChange={f1}
 onEdgesChange={f2}
 onConnect={f3}
 onNodeDoubleClick={f5}
 onPaneClick={f6}
>
</ReactFlow>
```

### エッジの経路は自動描画。

ノードとノードの接続線をどういう経路の線で表現するかは自動で判断/描画してくれます。
逆に、エッジがここを通るように描画～ということが可能か、知見が少なくわかっていません。
ただこれはライブラリの目的/用途が違うケースだと思うので、意図通りに線を引きたいという要望であれば素直に基本的な図形描画ライブラリに任せる方が賢明でしょう。

# 最後に

求めるUIに対し、どのライブラリが適しているか検討するのは都度必要かと思います。
しかし逆に、機能的にはあれもこれも足りているという場面も出てくることでしょう。
その際はライブラリの扱いやすさ(簡潔さ、挙動の素直さ)なども加味してみては如何でしょうか。より開発がスムーズになることと思います。

React Flowのすすめ

# はじめに

Tailwind CSSでprimary colorやsecondary colorを設定したのでやり方を纏めました。

# primary colorやsecondary colorの設定方法
## Tailwind CSSとは
手軽で簡単にスタイルの設定ができるCSSのフレームワーク。
その中で今回は色について記載していきます。

## 色の種類
Tailwind CSSでは22種類の色の濃さによって各10種類、計220種類プリセットとして用意されています。
この中から好きな色を選んで使用することができます。

## 色の設定
tailwind.config.js にprimary colorとsecondary colorを設定したい場合は、このように色を記載します。

```js
module.exports = {
 theme: {
 colors: {
 primary: '#4f46e5',
 secondary: '##a855f7',
 }
 }
}
```

## 実際の使用方法
クラス名にこのように記載することで使用できます。
```css

```

# まとめ
Tailwind CSSを初めて知ったのですが、簡単にcssが設定できました。
特に色を一括で設定できるところがありがたいなと思います。

# 参考
[Tailwind CSS公式サイト](https://tailwindcss.com/docs/customizing-colors)

最近公開された記事