当ブログでもちょこちょこ取り上げてはいましたが、改めて。
タイトルの通り、SPA（Angular）+AWS Lambda（Python）のクラウドアプリケーションを開発してみました。
※２０２０年８月、諸事情により非公開にしました。
（まだSEO的なトコロまで手を加えられていないので、リンクカードが寂しい…。）
少し前には議員さんの「クラウド」発言で「サーバー」が騒がれましたが、特定の技術に目を向ければあながち間違いでもないんですよね。
そこまで知っていたのかどうかは、また別のお話ですが。
ともあれ、一人で開発を進めるにあたってかなり苦戦しました。
その記録を残しておかない手はないと思い、今後は開発期間中にぶつかった壁の数々をご紹介していこうと思います。
ひとまず今回は、開発したアプリケーションに使用した技術だけご紹介していこうと思います。
使用した技術をざっくり説明（表面的）
表面的なトコロで見ればタイトルの通りなのですが、実際にはもっと色々な技術を駆使して開発を行いました。
まずは表面的なトコロから、後半は連携などで利用したサービスに関してもざっくり説明していきます。
SPAとは
Single Page Applicationの略です。
Webサイトはサーバーにリクエスト（ページを開きたい、データを取得したいなど）を送り、サーバーがそのリクエストに対してレスポンスを返すことでブラウザの表示内容が更新されます。
このレスポンスにHTMLを含めるのがSPAではない従来型のシステムです。
Webサイトで何かアクションを起こした際に、アクション後のページが丸ごとサーバーから返ってくるというイメージです。
SPAはというと、最初にWebサイトにアクセスした時点で全てのページ情報を読み込んでしまいます。
そしてその後のリクエストに対するレスポンスは全てデータのみで、ページの情報は含まれません。
これにより従来型と比較して、リクエスト⇔レスポンスでやり取りするデータが減ることでWebサイト内での処理速度が向上します。
Angularとは
Webアプリからモバイルアプリケーションまでを網羅するフレームワークです。
Googleが開発元となっているため、Googleが考えるベストプラクティスが色濃く見受けられるのも特徴の一つです。
Vue.jsに若干押されているような気もしますが、まだまだ人気のあるフレームワークだと信じています。
AWS Lambdaとは
Amazonが提供する、Amazon Web Serviceの中の一つのサービスです。
冒頭でも若干触れましたが、AWS Lambdaを利用することでサーバーレスアプリケーションの構築が可能です。
どういうことかというと、バックエンド処理をラムダ関数として登録しておくことで、AWS Lambdaに対してリクエストを行った際に、リクエストと紐づけられている関数が実行される、という仕組みになっています。
今回AWS Lambdaを選択した理由としては、AWSでWeb APIを構築するにあたってはEC2インスタンスを作成することが一般的だと思いますが、EC2インスタンスは起動時間に応じて料金が発生してしまう為「開発したは良いものの全然利用者がいない！」なんて状況でも請求が発生するのに対し、Lambdaであればリクエスト単位で料金が発生する為、立ち上がりのサービスにはうってつけだと判断したからです。
まぁ、つまり今回開発したアプリケーションの利用者がEC2インスタンスの利用料金を満たせるほど増えるとは思っていなかったわけですが。
あとはEC2インスタンスの構築にあたっては、サーバー（Linux）の知識も必要になるため、最速のリリースに向けて「そこで苦戦したくない」という思いもありました。
結果として同等レベルで苦戦したんですけどね。
Pythonとは
近年、ライブラリの豊富さからAI分野での活用が期待されている言語です。
PythonだけでもWebシステムを完結させてしまえるのですが、今回はWeb APIとしての利用のみ。
先に言っておきますが、初心者向けの言語ではないと感じました。
使用した技術をざっくり説明（内面的）
続いて連携などで利用したミドル・サービスに関してです。
Angular Materialとは
Angularの開発元と同じGoogleが提供する画面コンポーネントライブラリです。
以前にも当ブログで紹介しています。
ここ最近仕事でもプライベートでも使っているAngularですが、さすが新しい技術だけあってある程度の要素（例え…
Angular Flex Layoutとは
Angular用のCSS拡張ライブラリ（？）です。
コチラも以前に当ブログで紹介しています。
Webシステムを開発する場合、業務系であれば標準機能を利用して開発していけばいいのですが、例えばコンシューマー…
Swaggerとは
コチラも以前に当ブログで紹介していますが、WebAPIアクセス用のクラス作成に利用しました。
Swaggerって知ってますか？APIの開発に役立つツールのようです。 仕事で触れる機会があり、これは便利だと…
RDSとは
AWSが提供するデータベースです。色々なDBが提供されていますが、今回はMySQLを利用しました。
Code Commitとは
AWSが提供するソース管理用のリポジトリです。
開発当初はBackLogのGitリポジトリを利用していましたが、後述するAmplifyとの連携や今後の開発を見据えて途中で移行しました。
Amplifyとは
AWSが提供するWebアプリケーション実行環境です。
先述したCode Commitなどのリポジトリと連携することで、リポジトリの内容変更時に自動でビルド・デプロイまでを行える優れものです。
さらにAmplify上にデプロイしたアプリケーションを公開することも可能。しかもブランチごとに環境を作ることが出来ます。素晴らしいの一言。
SourceTreeとは
Atlassianが提供するGit用GUIツールです。
Flaskとは
Python用のマイクロフレームワークです。
当初はDjangoを使おうかとも考えたのですが、規模も小さかったので軽量なフレームワークを選びました。
最初に言っておくと、日本語の情報は少なく、英語の読解力が必要になります。
API Gatewayとは
AWSが提供するエンドポイントです。
Lambdaに作成したWebAPIのエントリポイントとして使用しました。
Route53とは
AWSが提供する…なんていうんでしょうね。
とりあえずAmplifyにデプロイしたアプリケーションへのエンドポイントや、API Gatewayに設定したエンドポイントをドメイン名に切り替えるためにドメインを購入するのに使いました。
Simple Email Serviceとは
略してSES。AWSが提供するメールサービスです。
Lambdaに定義したWebAPIからメールを送信する際に使っています。
Zappaとは
Pythonをサーバーレスアプリケーションとしてデプロイする際に利用したライブラリです。
情報は決して多くありませんでしたが、コマンド一発でPythonのコードをLambdaに定義し、API Gatewayの設定までを行える優れモノです。
その他
Lambdaの実行ログ用にCloud Watch、Zappa利用に際してS3とCloud Formationを利用しています。
その他にも…IAMとかCertificate Managerとか。
とりあえずここまで書いてみて
頭が痛くなりそうでした。
改めて振り返ってみると、簡単なアプリケーションにもかかわらず、色々なサービスを利用していたことに気付かされました。
使い勝手はまだイマイチですが、これをプライベートの時間だけで１ヶ月かからずに構築したのはなかなかじゃないでしょうか？
でも慢心はいけません。今後はさらに改善してサービスとして少しでも多くの人に利用してもらえるように努めなければなりませんから。
使用した技術をざっくり紹介したところで、次回からは言語・サービス別に苦戦したところを書いていこうと思います。
以上です。
スポンサーリンク
