当ブログでもちょこちょこ取り上げてはいましたが、改めて。

タイトルの通り、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 Flex Layoutとは

Angular用のCSS拡張ライブラリ(?)です。

コチラも以前に当ブログで紹介しています。

Swaggerとは

コチラも以前に当ブログで紹介していますが、WebAPIアクセス用のクラス作成に利用しました。

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とか。

とりあえずここまで書いてみて

頭が痛くなりそうでした。

改めて振り返ってみると、簡単なアプリケーションにもかかわらず、色々なサービスを利用していたことに気付かされました。

使い勝手はまだイマイチですが、これをプライベートの時間だけで1ヶ月かからずに構築したのはなかなかじゃないでしょうか?

でも慢心はいけません。今後はさらに改善してサービスとして少しでも多くの人に利用してもらえるように努めなければなりませんから。

使用した技術をざっくり紹介したところで、次回からは言語・サービス別に苦戦したところを書いていこうと思います。

以上です。

スポンサーリンク