Help us understand the problem. What is going on with this article?

初めてAngularを使ってデモプログラムをつくってみたときにわかったこと9つ

わたしはこれまで主にjqueryを使ったシステムの開発を行ってきましたが、udemy/Youtubeのオンラインコースを受講し、angularを使ったシステム開発の基礎を学びました。
その際、Angularを初めてとするSPA(Single Page Application)の作り方はこれまでと比べて、大きく考え方が異なる箇所がいくつかあることがわかったので、それらをここで整理してみます。

ここでは、SPA以前のフロントエンド開発手法を複数ページを前提に作ることかMPA(Multi Page Application)と呼ぶことにします。
(一応、ここでそのように呼ばれているので。一般的なのかどうかは知りませんが、、、)
https://medium.com/@NeotericEU/single-page-application-vs-multiple-page-application-2591588efe58

開発方針・制約

①クライアントサイドとサーバサイドのプログラムは疎結合

MPAではクライアントからのアクセスがあるとそれをサーバ側で受け取り、次のページを返す動きをするため、サーバプログラムとは切り離せない関係にありました。
SPAでは基本的な画面遷移はクライアント側でのみ完結し、データが必要な時のみサーバにアクセスする。接続先はリクエストを出すときに指定ができるため、同じサーバ、ドメインである必要がありません。
そのため、クライアントサイドのプログラムはapache やAmazonS3などの静的サイトのみ公開できる環境に配置することも可能です。

②クライアントサイドのプログラムは静的サイトなどにおいておくことができる

MPAでは、サーバ側に都度リクエストを行い、サーバ側で動的にhtmlを作成させるため、クライアントとサーバーは切り離せない関係にありました。
SPAの場合、サーバとクライアントは疎結合となるため、別のサーバに配置されていても問題はありません。
また、クライアントサイドのプログラムはapacheやamazon S3など、静的なページのみを扱うサーバに配置しても問題なく動作させることができます。←個人的にはこれが一番驚きでした。

③サーバを介さなくても、画面間で値の持ち回りができる

MPAでは画面更新の際、その値を一旦サーバに渡すか、クッキーやローカルストレージなどに入れないと値を画面間で持ち回ることはできませんでした。SPAではサービス内の変数に値を登録しておけば簡単に持ち回ることができます。(angularの場合)

④サーバとの通信はRESTでおこなう

MPAの場合、基本的には毎回サーバ側にGETかPOSTでアクセスを行い、毎回すべてのページ情報をサーバから受け取るという形であった。対して、SPAでは必要な情報だけを受け取り、ページ内の該当する部分を更新するという形となる。

⑤セッション使わない(で済む)

MPAの場合、画面間の値の持ち回りの方法を簡略化するため、また、ユーザーの認証・認可情報などを持ち回るためにセッションを利用することが一般的でした。
SPAの場合、値の持ち回りはjavascript の変数内に保存しておけばよく、また、認証・認可の情報はjwtなどを使ってトークン内に持たせるというのが一般的になっているため、セッションを使う必要があまりありません。
セッションを利用すると、サーバーの負荷によってスケールアウトやスケールダウンする際のが難しくなってしまうので、できるだけ利用しないようにした方がよい様です。

⑥テンプレートエンジンの利用が不要

MPAの場合、sitemeshやapache tileなどを使い、サイドメニューや画面上のロゴなどが共通的に出力されるように設定を行う必要がありました。SPAの場合、最初の読み込み後はコンテンツ部分のみを入れ替えるようにするため、この部分の考慮が不要になります。

⑦複数のサーバと通信可能

クライアントとサーバが切り離されているため、クライアントはどこのサーバへでもアクセスできます。取得するデータによって接続するサーバを切り替えることも可能です。
例えば、機能AではGithubから開発者の情報を取得し、機能Bでは本の情報をAmazonから取得した情報を表示することなどもできます。

認証系

⑧認証を別サーバで行うことができる。

認証をする際は、どこかに認証情報(IDパスワード)を渡して、連携先のサーバが理解できるトークンが入手できればよい。先述の通りクライアントとサーバは疎結合なので、認証先は最初にアクセスしたサーバ以外でもよい。(この場合、認証の際は両者から受け取った情報を裏で認証サーバに投げるというやり方となる)

⑨認可はトークンで行う

認証・認可は最初の認証で認証サーバからtokenを受け取り、認証完了後はそのトークンをリクエストヘッダ(Authentication: が一般的)に含めることでサーバ側に誰のリクエスト化を伝えるする形が一般的。
tokenの格納先はlocalStorage、また、token改ざん防止のためにJWTを使う

まとめ

特に他のサーバにクライアント側からリクエストを投げる点、セッションを使わない点など、MPAに慣れている人は違和感を感じるかもしれないです。(私もその一人)
でも複雑な部分はフレームワーク側が吸収してくれており、開発の際の記述はかなりシンプルになります。
そのため、最初に学習コストはかかりますが長期的にはこちらの方が記述しやすく、メンテもしやすいと思います。

また、Angularなら今流行りのマイクロサービスの実現も、比較簡単に実装できそうです。
(これまでマイクロサービスのサービスを聞いて概念的には理解していましたが、具体的にどうやって実装すればよいのかをイメージすることが難しかった)
マイクロサービスは、クラウドと相性が良いため、最初は最小スペックで公開し、
負荷に応じて自動スケールアウトしておけばコストを最小限に抑えることもできるというメリットもあります。

次に新規でシステムを開発する時は、ぜひSPAで開発しましょう!(したい)

参考ページ

Why do not you register as a user and use Qiita more conveniently?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away