垣見です。
前後編ハンズオンのうちバックエンド編（DynamoDB ×Lambda ×API Gateway）です。
「サーバレスアプリ」という言葉に、「何から始めたらいいのかわからない」「構成が分からない」と敷居が高く感じている人向けのブログです。
このブログでは、AWS上のサーバレス構成で動くWebアプリを、最初の始め方からバックエンドの作り方まで初心者向けに丁寧に解説します。
コードが分からなくても、AWSが分からなくても大丈夫です。一つずつ説明していきます。
- はじめに
- 今回作るもの（再掲）
- 全体の流れ（再掲）
- 【座学】そもそも「サーバレス」って何？
- 【座学】バックエンド開発の基礎
- DynamoDBの用意
- Lambdaの用意
- 【座学】API Gateway について
- 【実践】API Gateway と Lambdaを繋ぐ
- 【実践】フロントエンドとバックエンドを繋いでみよう
- おわりに
はじめに
この前後編のブログは、筆者が2025年のANGEL Dojoに参加して学んだサーバレスアプリケーションの作り方を座学を交えたハンズオン形式でまとめたものになります。
前編では、S3上で動くReactアプリケーションのフロントエンド側を実装しました。
これをもとにAWSのサーバレスリソースを使って、バックエンド側を開発していきます。 なお、今回は最低限の開発手法ということで、IaCなどは使わず、コンソール上での直接開発になるのでご留意ください。
今回作るもの（再掲）
今回は、日々のちょっとした「できたこと」を記録して、自己肯定感を高めるためのWebアプリを作ってみましょう。 機能はとてもシンプルで、以下の2つです。
- 今日「できたこと」をテキストで入力し、登録できる
- これまで登録した「できたこと」の一覧を閲覧できる
「なんだ、それだけ？」と思うかもしれませんが、このシンプルな機能の中に、Webアプリの基本となるデータの登録（書き込み）とデータの取得（読み込み）、また、「AWS Lambdaを使ってAWSサービスを操作する方法」という非常に重要な要素が詰まっています。
ここをマスターすれば様々なアプリに応用が利くようになるので、是非気になるところから見てみてください。
また、このブログは汎用性を意識して書いています。皆さんは上記記載のアプリを一緒に作っても良いですし、オリジナリティのあるアプリを作るための参考としても大丈夫です。その場合は都度読み替えていただければと思います。
全体の流れ（再掲）
このブログでは、以下のステップでアプリを開発していきます。
【前編】
- Amazon Q Developerの準備: まずは、私たちの代わりにコードを書いてくれるAIアシスタントを使えるようにします。
- フロントエンド（見た目）の作成: ユーザーが実際に操作する画面を、Amazon Q Developerに作ってもらいます。
- S3静的ウェブサイトホスティング設定: ユーザーの作った画面をS3において、ウェブサイトとして見られるようにします。
【後編】
- バックエンド（裏側の仕組み）の作成:
- DynamoDB (データベース) の用意: 記録した「できたこと」を保存しておくための箱を作ります。
- Lambda (機能) の用意: データを保存したり、取り出したりする具体的な処理を担当するプログラムを作ります。
- API Gateway (窓口) の用意: フロントエンドからの「このデータを保存して！」「データの一覧をちょうだい！」というお願いを受け付ける窓口を作ります。
- フロントエンドとバックエンドの接続: 作った見た目と裏側の仕組みを繋ぎこんで、アプリを完成させます。
【座学】そもそも「サーバレス」って何？
サーバレスの概念
このブログでは「サーバレス」という構成でアプリを作りますが、最初にこの言葉を簡単に説明します。
（「サーバー」が分からない方は初めは「計算機・コンピューター」のようなものだと読み替えるといいと思います。）
「サーバレス（Serverless）」は、直訳すると「サーバーが無い」ですが、本当にサーバーが無いわけではありません。 Webサイトやアプリを動かすには必ずサーバーが必要になります。では何が違うのかというと、「サーバーの管理を自分たちでやらなくていい」というのがサーバレスの大きな特徴です。
例えば、5秒で終わるような計算をコンピューターで行いたいと考えたとき、選択肢は2つあります。
- 選択肢A: その計算のためだけに、超高性能なコンピューターンを自分で買ってきて、常に電源を入れておく。（これが従来のサーバーを持つ考え方）
- 選択肢B: 超高性能なコンピューターを何千台も持っている専門の会社に行って、計算したい5秒間だけ1台借りて、5秒分の料金を払う。（これがサーバレスの考え方）
↑※「PC」となっていますが別にパーソナルではないですね…
選択肢Bのほうが、圧倒的に手軽でコストも安く済みそうですよね。 このように、インフラ（サーバーなど）の準備や管理をAWSのようなクラウド事業者にすべてお任せし、私たちは「やりたい処理（コード）」を置くだけで済む。これがサーバレスの基本的な考え方です。
AWS上でのサーバレスの概念
ただ、これだと「オンプレミス環境と比較すれば、AWSのサービスはすべてサーバレスではないのか？」という疑問が浮かぶかもしれません。（自分は思いました。）しかし、違います。
例えば、仮想サーバーをレンタルできる「Amazon EC2」はサーバレスとは呼ばれません。
EC2のようにサーバレスではないリソースはAWSが用意してくれた仮想的なサーバーを１台まるっと借りるようなイメージのサービスです。AWSは物理マシンの管理はしてくれるものの、その上で動くOS以上のレイヤー（OS、ミドルウェア、アプリケーションなど）は、我々ユーザーの責任範囲となります。
OSのセキュリティパッチをあてたり、ミドルウェアの設定をしたり、コンピューターの上のアプリケーション全般を管理する必要が出てきてしまうということです。
単純な1+1の結果だけ出してほしいときに、OSのセキュリティについて気にしなければいけないのは面倒くさいです。
それすら考えなくてよく、コードの実行をお願いすればその計算結果部分を受け取れるのが、AWS Lambdaをはじめとする「サーバレス」サービスとなります。
また、料金体系にも大きな違いがあります。
EC2やAmazon RDSは、インスタンスが起動している時間に対して課金されます。インスタンスを立ち上げている時間はずっとインスタンス（サーバー）を借り続けている状態扱いになるため、たとえ目的の処理を実行していない時間帯でもお金がかかります。
一方Lambdaに代表されるサーバレスサービスは、AWSが管理しているサーバーの1領域をその計算の間だけ借りるような形になるため、コードが動いていない間は全くお金がかかりません。コードが実行された回数と処理時間に対してのみ課金されるので、単純な処理の実行をさせたい場合は費用対効果に優れています。
次にスケーラビリティです。例えば、キャンペーンなどでWebサイトへのアクセスが一時的に集中した場合でも、それに合わせてAWSが自動で処理能力を引き上げて対応してくれます。開発者は、こうした突発的な負荷変動を予測してインフラを準備・管理する手間から解放されます。
つまり、サーバレスとはサーバーの存在や性能（キャパシティ）を意識することなく、実行したいコードを配置するだけで、コストとスケーラビリティが自動的に最適化されるクラウドの新しい利用形態と言えます。これにより、開発者はインフラの管理に煩わされることなく、ビジネス価値の創造に専念できるのです。
サーバレスな構成のアプリとは？
さて、ここまではLambdaを例に「サーバーを管理せずコードを実行する」というサーバレスの部品について見てきました。 では、これらの部品を組み合わせて、ユーザーが実際に触れる一つのアプリケーションにするには、どういった構成になるのでしょうか？
サーバレスなアプリケーションは、ひとつの大きなサーバーで全てを動かすのではなく、それぞれ専門的な役割を持った複数のAWSサービスを組み合わせて構築します。
今回の「できたことログ」アプリで言えば、以下のようなイメージです。
Amazon S3: フロントエンドの置き場所（HTML/CSS/JavaScriptファイル）Amazon API Gateway: アプリの「総合受付」。ユーザーからのリクエスト（APIコール）を受け付け、適切な処理に繋ぎます。AWS Lambda: アプリの「脳」。データの登録や取得といった実際の処理（ビジネスロジック）を実行します。Amazon DynamoDB: データを保存する「データベース」。
ユーザーからのリクエストは、以下のような流れで処理されます。
「使いたいときにその時だけサーバーを貸して計算してもらう」のがサーバレスです。その時間帯にやりたいことによって動かすAWSサービスを変え、お互いに連携してデータを渡しあう構成になります。
サービスごとに得意なことが違うので1つの高性能なサーバーを動かして全部を実行してもらうよりも柔軟で、かつ別のサービスの呼び出しを増やす際も全体への影響が少ない、拡張性に優れたアプリケーションになるという訳です。
なぜANGEL Dojoで推奨されるの？
ANGEL Dojoのような短期間で成果を出すハッカソンでは、サーバレス構成は非常に有効です。
- 疎結合（そけつごう）にしやすい: サーバレスでは、機能を独立させて作ることが推奨されます。ひとつのサーバー内にコードが集結しない構成になるため、一つの部品を修正しても他の部品に影響が出にくく、変更や機能追加が楽になります。
- アジャイルに進めやすい: 「使うときだけ課金」がなされて費用対効果に優れたサーバレスサービスは、「とりあえず作って動かしてみる」が簡単にできます。サーバレスなら、サーバーの構築や設定に時間を取られることなく、すぐにアプリケーションのロジック開発でPDCAを回すことができます。
サーバレスじゃないほうがいい場合は？
もちろん、サーバレスが常に最適解というわけではありません。以下のようなケースでは、従来のようにサーバーを自分で管理する構成（EC2など）のほうが向いていることもあります。
- 常に高い負荷がかかり続ける場合: 常に大量のアクセスがあるような大規模サービスの場合、ミリ秒単位の課金であるサーバレスより、高性能なサーバーを月額でレンタルしたほうがトータルコストが安くなることがあります。
- 特殊なソフトウェアや設定が必要な場合: OSのバージョンを細かく指定したり、特殊なライブラリをインストールしたりする必要があるシステムを動かす場合は、自分で自由に環境を構築できるサーバーのほうが適しています。
今回の「できたことログ」アプリのような、いつアクセスが来るかわからない小〜中規模なアプリケーションには、サーバレスはまさにうってつけの技術と言えるでしょう。
【座学】バックエンド開発の基礎
考え方
さて、ここからはアプリの裏側、バックエンドを作っていきます。
前編で作ったフロントエンドだけでは、画面更新をしたらすぐに入力したデータが消えてしまいました。また、Aさんが入力した内容をBさんに共有する、ということもできません。
これを解決するのがバックエンドです。 フロントエンドを実行するのはユーザーの持つ個別端末（とそのうえで動くブラウザ）ですが、バックエンドはサービス提供者の管理するサーバ上で動きます。ここで色々なデータを保持したり、ユーザー側で行うには重たく複雑な計算を実行したりすることで、多数の顧客を想定したサービスを提供するようなアプリケーションが成り立ちます。
API仕様書を作って、開発をスムーズに進めよう
API仕様書とは？
本格的にバックエンドを作り始める前に、API仕様書をご紹介します。 これはフロントエンドとバックエンドの間でデータをやり取りするためのルールのようなものです。
- どんなデータをリクエストできるか？: 「できたこと」の一覧取得、新しい「できたこと」の登録など。
- どうやってリクエストするか？: どのURLに、どんな形式でお願いすれば良いか。
- どんなデータが提供されるか？: 成功したらどんなデータが返ってくるか、失敗したらどんなエラーメッセージが返ってくるか。
これらを事前に文章で定義したものがAPI仕様書です。
API仕様書を作るメリット
API仕様書を最初に作る最大のメリットは、フロントエンドとバックエンドの開発を並行して進められる点にあります。
仕様書を「合意書」として運用することで、お互いが相手の完成を待つ必要がありません。
- フロントエンド担当: バックエンドがまだ未完成でも、API仕様書通りにデータが返ってくる前提で、ダミーのデータを使って見た目の開発をどんどん進められます。
- バックエンド担当: フロントエンドのデザインを待たなくても、API仕様書通りに機能するように、裏側の仕組みをどんどん作れます。
これによりコミュニケーションコストが下がるので、開発スピードが格段に向上し、手戻りも少なくなります。
「数年後にそのAPIを改修する」となったときも、仕様書があれば思い出しやすいです。
もちろん一人で開発する場合でも、頭の中を整理し、作るべきものの全体像を把握するために非常に役立ちます。
チームのルールとして「このフォルダに用意しておく」のように決めておくなど、合意をしておくと良いと思います。
運用で作るタイミング
今回はブログの構成の関係上先にフロントエンドを作ってしまいました。（Qを使ったフロントエンドプロトタイプは企画段階でのイメージ共有にも向いているかと思います）
しかし、本来は一番最初に要件定義として作るのが望ましいです。 スクラム開発の場合も最初にある程度決めてから実施するのがいいかと思います。
【実践】API仕様書・テーブル定義とバックエンド実装計画書を作ってみよう
事前にVSCodeでOpenAPI (Swagger) Editorの拡張機能をインストールしておきます。
/project/docs/achievement-log-app-specification.md を読み込んでください。 現在フロントエンドだけがこのproject/配下に存在します。S3静的ウェブサイトホスティングの予定です。 これからAWSのバックエンドを作っていきたいです。 IaCではなく、コンソールを直接操作する形で実施していきます。 まずは、API仕様書ファイルとDynamoDBのテーブル定義をproject/backend配下に、バックエンド作成の手順書をproject/docs/backend配下においてください。 なお、わからないことがあれば先に聞いてください。
ユーザー側でよく知らない領域や複雑になりそうな領域を聞くとき、「なお、わからないことがあれば先に聞いてください。」のような文言を入れると、Qが曖昧な部分を最初に聞き返してくれます。
知らないうちに思わぬ実装がされない様にしたり、また知らない領域について学んだりするのによいプロンプトだと思っています。
ひとまず、以下のように返します。
認証機能: ユーザー登録・ログイン機能は必要でしょうか？それとも匿名での利用を想定していますか？→今は考えなくてよいです。 データの永続化: 各ユーザーが自分の達成記録のみを見られるようにするか、全体で共有するかどちらでしょうか？→全体共有で良いです。 API仕様書の形式: OpenAPI（Swagger）形式で作成しますか？それとも別の形式をご希望ですか？→OpenAPI形式でお願いします。 Lambda関数の言語: 仕様書にはPythonと記載がありますが、これで進めてよろしいでしょうか？→はい、お願いします。 DynamoDBのテーブル設計: 単一テーブル設計か、複数テーブル設計かご希望はありますか？→AWSのベストプラクティスに則った方式で設計してください。
api-specification.yamlがAPI仕様書です。
以下のようにYAML形式でどんなパスにどんなデータが入るのかを定義しています。ただ、これだと見にくいです。
API仕様書の一部。長いので折り畳み
openapi: 3.0.3
info:
title: できたことログアプリ API
description: 日々の達成感を記録し自己肯定感を高めるためのWebアプリケーションのAPI
version: 1.0.0
contact:
name: Achievement Log App
servers:
- url: https://api.achievement-log.example.com
description: Production server
- url: https://dev-api.achievement-log.example.com
description: Development server
paths:
/achievements:
get:
summary: 達成記録一覧取得
description: 登録されている全ての達成記録を新しい順で取得
operationId: getAchievements
tags:
- achievements
responses:
'200':
description: 達成記録一覧の取得成功
content:
application/json:
schema:
type: object
properties:
achievements:
type: array
items:
$ref: '#/components/schemas/Achievement'
count:
type: integer
description: 取得した達成記録の件数
example:
achievements:
- id: "01HN123ABC456DEF789"
content: "朝早く起きて散歩をした"
createdAt: "2024-01-15T06:30:00.000Z"
- id: "01HN123ABC456DEF788"
content: "プレゼン資料を時間内に完成させた"
createdAt: "2024-01-14T18:00:00.000Z"
count: 2
'500':
$ref: '#/components/responses/InternalServerError'
そこで、ファイルを開いた状態で Ctrl + Shift + P(MacならCmd + Shift + P) を押し、OpenAPI: show preview using Swagger UIと入力して実行することで、横にSwagger UIのプレビュー画面が出てきます。
この画面では、どのエンドポイント（URL）で、それぞれ何ができるのか（GET/POSTなど）、どんなデータが返ってくるのかを、視覚的にわかりやすく確認できます。 さらに、この画面の「Try it out」というボタンからはその場でAPIの動作確認ができます。
開発中の確認がしやすいツールです。
この章でテーブル定義や構築手順もある程度書いてもらえたので、進めていきましょう。
DynamoDBの用意
【座学】DynamoDBとは？
Amazon DynamoDBは、AWSが提供するデータベースサービスの一つです。データベースとはその名の通りデータを保存しておく場所で、Excelの表をイメージすると分かりやすいかもしれません。
DynamoDBはAWS上のデータベースの中でも「NoSQL」という種類に属しており、コスト効果が高く、レイテンシが低く、サーバレスで運用負荷が少ない、というメリットがあります。
Amazon RDSなどと比べてデータ構造は柔軟（=非厳格）で、膨大な量のデータを非常に高速に処理できるのが特徴です。検索機能や多対多での値の保持などDynamoDBが不得意とする機能もあるので、DB選定はやりたいことを考えて選ぶのが良いです。
今回は単純な1件の情報だけのやり取りということで、安価なDynamoDBを採用します。
今回はこのDynamoDBに、ユーザーが「できたこと」を一つずつ入力・保存でき、そしてフロントエンド側でそのDBの内容を読み取って画面で見られるようにしていきます。
【実践】コンソール上でDynamoDBのテーブルを作り、データを2件入れてみよう
まずは、データを保存するための「テーブル」（Excelでいうシートのようなもの）を作成しましょう。
先ほどQに生成させた手順書をもとに作っていきます。 Qは他のLambdaの仕様やAPI定義を知っているので、それをもとに作ると入力が少なく楽です。
- AWSマネジメントコンソールにログインし、サービス検索で「DynamoDB」と入力して開きます。
- 「テーブルを作成」ボタンをクリックします。
- テーブル名に
achievements等の名前を入力します。 - パーティションキーに
idと入力し、型は「文字列」を選択します。これは、各データを一意に識別するための番号やIDのようなものです。
- 他の設定はデフォルトのままで、「テーブルを作成」をクリックします。
1分程度待つと、テーブルが作成されます。
作成されたテーブルを選択し、「アクション」から「項目を作成」をクリックして、手動でデータを2件ほど入れてみましょう。
id には 1 や 2、そして「属性の追加」から「文字列」を選び、content という名前で「テストデータ１」のように内容を入力します。
必要があれば、GSI（Global Secondary Index）を活用しよう
DynamoDBのグローバルセカンダリインデックス（GSI）は、元のテーブルとは異なるパーティションキーとソートキーを使って、効率的なデータクエリを可能にするためのインデックスです。 これにより、アプリケーションは多様なクエリパターン（アクセスパターン）に対応でき、基本のキーでは検索しにくいデータも高速に取得できます。
Lambdaの用意
【座学】Lambdaとは？
AWS Lambdaは、サーバーのことを一切気にせずにプログラムコードを実行できる、サーバレスな関数実行サービスです。
AWSはPythonなどのコード内でコマンドを書くことで、DynamoDBやBedrockを操作できるようなライブラリを用意しています。これにより、Lambdaを使って柔軟な条件分岐などで他のAWSリソースを操作できるようになるという訳です。
なお、Pythonを使ってAWSリソースを操作するには、「boto 3」というライブラリを利用します。 boto 3を自力で書いたり調べたりできるようになりたい人はこちらの入門ブログもお勧めです。
【実践】DynamoDBからデータを採ってくるLambdaを作ってみよう
では、先ほどAmazon Qが生成した「DynamoDBにデータを書き込むコード」を使ってコンソールを設定していきましょう。
もしまだコードが無ければ、例えば以下のようなプロンプトで生成してもらいましょう。
API Gateway経由のAWS Lambdaで動かすPythonのコードを生成してください。 DynamoDBからデータを採ってくるLambdaコードを生成します。 -フロントエンドのコードは`<該当のパス>`にあります。 - API仕様書は`project/backend/api-specification.yaml`, DynamoDBテーブル定義は`project/backend/dynamodb-sample-data.json`, `project/backend/dynamodb-table-definition.json`にあります。 - `project/docs`配下にコンソール上での設定手順書も作成してください。
生成されたコードをコピーし、Lambdaコンソールから「関数を作成」> get-achievementsのような名前で新しいLambda関数 (ランタイムはPython 3.12に変更) を作成し、コードを貼り付けます。
重要な点として、このLambda関数がDynamoDBを操作する権限を付与する必要があります。「設定」タブの「アクセス権限」から、ロール名をクリックして、DynamoDBへの権限を持つIAMロールをアタッチしてください。
※今はAWSLambdaBasicExecutionRoleとAmazonDynamoDBFullAccessを付けていますが、本番環境では最小権限に変更してください。
【実践】Lambdaのテストとエラーハンドリング
テストをしていきます。
初回のみ、テストデータを用意してあげる必要があります。
【実践】 DynamoDBにデータを入力するLambdaを作ってみよう
同様に、データを一覧で取得するLambdaも作ります。
生成されたコードを使い、create-achievementという名前でLambda関数を作成します。
こちらにも、DynamoDBへの権限を忘れずに付与しましょう。
今度はデータの入力（POST）イベントです。API定義書を見ると、Request bodyの欄にExample Valueが存在します。
先ほどのLambdaはこちらから何も渡さなくてもDynamoDBの中身を返すような仕様（GET API）でしたが、今度はこちらから入力するPOST APIを使います。そのため、テストイベントも特有のものにする必要があります。
Qに聞いてみましょう。
Lambda群のテストイベントを作ってください。
出来ました。
テストイベントを編集します。
【座学】API Gateway について
ここまでで、「Lambdaを使ってDynamoDBを操作する」ことはできるようになりました。 でも、肝心のフロントエンドがLambdaを呼ぶ方法がわかりません。 それを可能にするのがAmazon API Gatewayです。
そもそもAPIとはなにか
「Application Programming Interface」の略で、異なるソフトウェアやアプリケーションが機能やデータをやり取りするための接点（インターフェース）です。
と言われても、抽象的でよくわかりませんよね。
ざっくりですが、「アプリケーション上で、何かしらの機能を持ったボタン」と考えると良いです。 APIを使うと、「何かが起こる」。機能は何でもよいが、とにかくそのひとつのボタンやアクションに機能が詰まっている状態です。
API Gatewayとは
Amazon API Gatewayは、作成したLambda関数を、外部（今回はフロントエンド）から呼び出すための窓口（API）にしてくれるサービスです。
Lambdaで作った「機能」を、フロントエンド側から呼び出せる「WebのURLの形」のAPIにしてくれます。
フロントエンドはこのURLの形のAPIを呼び出すことで、後ろの複雑なLambdaを実行できます。
API Gatewayのメソッド
ボタンにも「押してただ決まった音が鳴るだけ」「音声入力してそれが文字起こしされる」など色々あり、その仕様によってこちらからのデータの渡し方が違うことは想像がつくかと思います。
それと同じでAPI Gatewayでも「メソッド」という形でユーザーのデータの渡し方やリクエストの種類をHTTPで定められた仕様に従って分類しています。
【実践】API Gateway と Lambdaを繋ぐ
HTTP APIを作成
- AWSマネジメントコンソールで「API Gateway」を開きます。
- 「APIを構築」から「HTTP API」の「構築」をクリック
- API名（例:
achievement-log-api）を入力し、「次へ」をクリックします。
- 「統合を追加」、「ルートを設定」「ステージを定義」はスキップして「次へ」をクリック
- 「作成」をクリック
ルートの作成
- 作成したAPIを選択
- 「ルート」タブの「作成」をクリック
GET /achievements ルート作成
- 以下の設定を入力：
- メソッド:
GET - リソースパス:
/achievements
- メソッド:
- 「統合をアタッチする」をクリック
- 以下の設定を入力：
- 統合タイプ: Lambda 関数
- Lambda 関数:
get-achievements
- 「アタッチ」をクリック
POST /achievements ルート作成
- 左ペインRoutesから「ルート」内の「作成」をクリック
- 先ほどと同様に以下の設定を入力：
- メソッド:
POST - リソースパス:
/achievements
- メソッド:
- 「統合をアタッチ」で以下を設定：
- 統合タイプ: Lambda 関数
- Lambda 関数:
create-achievement
- 「アタッチ」をクリック
CORS 設定
Webブラウザには、異なるドメインからのAPIリクエストをセキュリティ上ブロックする「同一オリジンポリシー」という厳格なルールがあります。 CORSは、APIサーバー側が「このドメインのWebページからならアクセスしてもOKだよ！」とブラウザに許可を伝えるための仕組みです。 この設定がないと、フロントエンドアプリからAPIを叩いたときにブラウザに弾かれ、APIが全く機能しないという事態に陥ります。（何度もエラーになりました）
現在は*を付けていますが、実際は最適な権限範囲に絞ったほうが安全です。
- 「CORS」タブをクリック
- 「設定」をクリック
- 以下を設定：
- Access-Control-Allow-Origin:
* - Access-Control-Allow-Headers:
Content-Type - Access-Control-Allow-Methods:
GET, POST, OPTIONS
- Access-Control-Allow-Origin:
- 「保存」をクリック
API Gatewayのテスト
- APIを選択。「呼び出す」エンドポイントからURLを取得できる。
- URLをブラウザに繋いでみる（この時点では何もないのが普通）
- URLの後ろにGETメソッドが存在するパス「/achievements」を付けると、そのAPIの正式パスなので情報がきちんと返ってくる。
【実践】フロントエンドとバックエンドを繋いでみよう
いよいよ最終段階です。フロントエンドのReactアプリを書き換えて、API Gateway経由でLambdaを呼び出し、データのやり取りができるようにします。
ここもAmazon Qの出番です。最初にモックを作ってもらったReactのコード（App.tsxなど）を開き、Qに以下のように指示を出します。
このReactコンポーネントを修正してください。 要件： - 画面が表示された時、API GatewayのGETエンドポイント (`<先ほどデプロイして発行されたURL/items>`) にリクエストを送り、コードが動くようにしてください。エンドポイントはgitignoreしてください。 - 「記録する」ボタンが押された時、入力欄のテキストをbodyに含めて、API GatewayのPOSTエンドポイント (`先ほどデプロイして発行されたURL/items`) にリクエストを送るようにしてください。 - データ登録が成功したら、一覧を再取得して画面を更新してください。 - データのやり取りには、axiosライブラリを使用してください。
Qが生成したコードを置き換えたあと、再度 npm run dev でローカル環境を立ち上げてみましょう。
入力欄に文字を打って「記録する」ボタンを押して、画面を更新しても消えず、DynamoDBに入力内容が反映されていれば成功です！おめでとうございます。
最後に、変更したフロントエンドのコードを再度ビルドし、S3にアップロードすれば、世界に一つだけのあなたのアプリが完成します。
おわりに
ブログには載せていないエラーを出しつつ、最後までたどり着きました。 自分でも動く画面のあるものが作れるんだ！という新鮮な感動があります。
UIデザインも、ロジックも、セキュリティも、この段階ではまだまだではありますが、Q DeveloperはANGEL Dojoのようなハッカソン・アイディアソンでは心強い味方になってくれることでしょう。
そんなわけで、このブログが少しでも皆様の参考になれば幸いです。
垣見(かきみ)(執筆記事の一覧)
2023年新卒入社 エンタープライズクラウド部所属 2025 Japan AWS Jr.Champions
図解するのが好き。「サバワク」のアイキャッチ作成も担当しています
