From 949c68ca88e2b2e3b89eecf137a15af06eb3cab7 Mon Sep 17 00:00:00 2001 From: r-fujimoto Date: Sun, 4 Aug 2024 13:36:59 +0900 Subject: [PATCH] fix (#167) --- src/server-app/overview/README.md | 100 ++++++++++++++++++------------ 1 file changed, 61 insertions(+), 39 deletions(-) diff --git a/src/server-app/overview/README.md b/src/server-app/overview/README.md index 3e0fb055..9c68c53e 100644 --- a/src/server-app/overview/README.md +++ b/src/server-app/overview/README.md @@ -2,25 +2,35 @@ footer: CC BY-SA Licensed | Copyright, Internet Initiative Japan Inc. --- -# サーバアプリケーション界隈Overview +# WebアプリケーションOverview + +## はじめに + +このOverviewでは、いわゆる「Webアプリケーション」をを構築するにあたり、サーバサイド側がどのような仕組みで動作するのか、様々なアーキテクチャパターンを紹介します。 +なぜアーキテクチャパターンを紹介するかというと、パターンはその時々で流行していたサーバサイドの言語やフレームワークと密接な関係があるためです。 +これらがどういう経緯や問題に対して登場したのかを見ていくことで特徴を把握し、今後の技術選択の材料にしてもらえると幸いです。 + +後半ではこれまたアーキテクチャとは切っても切り離せない、WebAPIの形式についても紹介します。 +これも各種メリット・デメリットがある分野なので、それぞれの強みと弱みをきちんと把握し、問題解決のため適切な技術選択をすることが重要です。 ## Webアプリケーションとは？ -世の中はWebアプリケーションで溢れています。 +はじめに「Webアプリケーション」とはどのようなものを指しているのか、ここでの認識を合わせておきます。 +昨今のIT業界はWebアプリケーションで溢れており、様々な形で登場します。 -この図の「Ruby on Rails」と書かれているのはWebアプリケーション。 +例えば、この図の「Ruby on Rails」と書かれている部分のことを「Webアプリケーション」と呼んだりします。 ![web_app_true1.png](./web_app_true1.drawio.png "web_app_true1") -次の図の「Perl CGI」もWebアプリケーション。 +次の図の「Perl CGI」も「Webアプリケーション」と呼ばれます。 ![web_app_true2.png](./web_app_true2.drawio.png "web_app_true2") -次の図の「Apache」はWebアプリケーションじゃない。 +一方で次の図の「Apache」は「Webアプリケーション」とはあまり呼ばれません。単純に「Webサーバー」と呼ばれます。 ![web_app_false1.png](./web_app_false1.drawio.png "web_app_false1") -次の図の「Go」は多分Webアプリケーション。 +次の図の「Go」も恐らく「Webアプリケーション」と呼ばれることが多いでしょう。 ![web_app_true3.png](./web_app_true3.drawio.png "web_app_true3") @@ -31,7 +41,7 @@ footer: CC BY-SA Licensed | Copyright, Internet Initiative Japan Inc. Webアプリケーションはwebの発展と共に様々な「書き方」と「動かし方」が提案されていました。 書き方が同じでも動かし方が変わったもの、言語を含めて書き方だけが違うやり方、様々です。 -この章では様々なWebアプリケーションの実装を「書き方」と「動かし方」それぞれの面で見ていきます。 +ここでは様々なWebアプリケーションの実装を「書き方」と「動かし方」それぞれの面で見ていきます。 大体登場した歴史順に紹介しますが、必ずしも新しいものが正しい・素晴らしいというわけではなく、「得意なユースケースは何か？」がポイントとなります。 ### CGI @@ -51,18 +61,20 @@ print ""; ``` - Common Gateway Interface の略 -- The Apache HTTP Server ("httpd") などのWebサーバでHTTPリクエストを受けて、外部プログラムにHTTPリクエストを渡し、出力をHTTPレスポンスとして返すしくみ。 -- Perlが大流行するきっかけとなった。 - - Perlは文字列処理が強力（C言語は文字列処理が貧弱） +- The Apache HTTP Server ("httpd") などのWebサーバでHTTPリクエストを受けて、外部プログラムにHTTPリクエストを渡し、出力をHTTPレスポンスとして返すしくみ +- Perlが大流行するきっかけとなった + - 当時の主流であるC言語の文字列処理が貧弱だったのに対し、Perlは文字列処理が強力だった - PerlからMySQL/PostgreSQLに接続してHTTPレスポンスを生成するスタイル -- 今日でもPerlで実装されたプロダクトは存続している（MovableTypeとか、mixiとか。CookPadもPerlでスタートしたはず)。 +- 少し前まではPerlで実装されたプロダクトが存続していたが、最近は流石滅多にないかも + - MovableTypeとか、mixiとか。CookPadもPerlでスタートしたはず - CGIの仕組み自体はPerl以外でもRubyやPython、シェルスクリプトなど文字列を出力できるプログラムであれば利用できる -CGIはHTTPリクエストを受けるごとに、新しいプロセスをforkする必要があり、Webサーバにとって負荷が高かった。 +CGIはHTTPリクエストを受けるごとに、新しいプロセスをforkする必要があり、Webサーバにとって負荷が高い特徴がありました。 ![perl_cgi](./perl_cgi.drawio.png "perl_cgi") -WebサーバのモジュールとしてPerlを動作させる「mod_perl」という方法が考案された（apache httpd + mod_perl 1998年) +そこで1998年頃にはWebサーバのモジュールとしてPerlを動作させる「mod_perl」という方法が考案されています。 +これによりプロセス管理をapache側で効率的に行えるようになりました。 ![mod_perl](./mod_perl.drawio.png "mod_perl") @@ -81,12 +93,12 @@ WebサーバのモジュールとしてPerlを動作させる「mod_perl」と （開発開始は1994年 実質的に最初の公開版PHP 3が1997年 本格普及はPHP 4で2000年) -1. CGIはHTTPリクエストを受けるごとに、新しいプロセスをforkする必要があり、Webサーバにとって負荷が高かった。 +1. CGIはHTTPリクエストを受けるごとに、新しいプロセスをforkする必要があり、Webサーバにとって負荷が高かった 1. 前述の通りmod_perlという形でPerlを動作させる手法が流行っていた 1. しかし当然ながらPerlはWebサーバのモジュールとして動作させる前提で設計・実装されたものではなく、使い勝手が悪かった 1. 類似の技術としてFastCGIというものもあったが、やはり癖があり使いにくかった -1. そこで最初からWebサーバのモジュールとして実行することを念頭に置いた、Webプログラミングに特化した処理系としてPHPが登場、大流行してPerlを駆逐する。 - 1. Facebookも長い間PHPで書かれていた。 +1. そこで最初からWebサーバのモジュールとして実行することを念頭に置いた、Webプログラミングに特化した処理系としてPHPが登場、大流行してPerlを駆逐する + 1. Facebookも長い間PHPで書かれていた 1. 元々はWebページを動的に生成するためのテンプレート的な言語であったが、機能が追加された結果スクリプト言語としての機能も持つ 1. 動かし方はCGI, mod_php（モジュール形式）などがあり、Perlの項目とほぼ同様の形式で動作する 1. 現在でも広く利用されており、[CakePHP](https://cakephp.org/jp) など今風のフレームワークも存在する @@ -142,14 +154,14 @@ JavaのテンプレートエンジンであるJSP(JavaServer Pages)の例 ``` -1. 1995年Sun Microsystems社がJava言語を売り出した。 - - 最初にアピールした`Applet`は、Webページの中にJavaのサンドボックス環境を埋め込んでアプリケーションを実行するというものだった。しかし制約が大きいうえにマシンパワーを要求するので、実用的なアプリケーションを作る環境としては、流行らなかった。 -2. しかしサーバサイドの技術として発表されたサーブレットは2000年ごろから流行し始め、2001年にStrutsが登場するとその人気は決定的になった。 - 1. サーブレットはHTTPリクエストを（CGIのようにプロセスをforkするのではなく)スレッドで処理するので性能が高かった。 - 2. Javaは静的に型付けされた言語であるため、Javaで書かれたアプリケーションはPHPよりも品質を確保しやすいかった。 - 3. WebアプリケーションフレームワークであるStrutsを使うと、プログラムを一定のスタイルで記述することを助け、同時に大人数で分業することを助けた。規模の大きなエンタープライズシステムの実装が可能になった。 +1. 1995年Sun Microsystems社がJava言語を売り出した + - 最初にアピールした`Applet`は、Webページの中にJavaのサンドボックス環境を埋め込んでアプリケーションを実行するというものだった。しかし制約が大きいうえにマシンパワーを要求するので、実用的なアプリケーションを作る環境としては、流行らなかった +2. しかしサーバサイドの技術として発表されたサーブレットは2000年ごろから流行し始め、2001年にStrutsが登場するとその人気が決定的になった + 1. サーブレットはHTTPリクエストを（CGIのようにプロセスをforkするのではなく)スレッドで処理するので性能が高い + 2. Javaは静的に型付けされた言語であるため、Javaで書かれたアプリケーションはPHPよりも品質を確保しやすいかった + 3. WebアプリケーションフレームワークであるStrutsによって大人数による開発が効率的に行えるようになり、規模の大きなエンタープライズシステムの実装が可能になった 4. Javaで書かれたコードはポータビリティがあり、サーバのOSやCPUが変わっても、そのまま実行できた。（まだx86系のCPUが市場を独占しておらず、SPARCやAlphaなどのCPUもある程度のシェアを持っていた。) -3. かくしてカジュアルな（コンシューマ向けの）WebアプリケーションはPHPで、シリアスな（エンタープライズ向けの）WebアプリケーションはJavaサーブレットで書く、という時代が続くことになった。 +3. カジュアルな（コンシューマ向けの）WebアプリケーションはPHPで、シリアスな（エンタープライズ向けの）WebアプリケーションはJavaサーブレットで書く、という時代が続くことになった ### Java EE / Spring @@ -193,16 +205,16 @@ public class HelloController { } ``` -1. Sun Microsystemsはサーブレットの成功に気を良くして、これを一層強力に推進してエンタープライズの世界を支配しようと試みた。そうして出てきたのはJava EE（Enterprise Edition）であった。 -2. Java EEは、エンタープライズアプリケーションを多数のサーバの連携する分散処理を通じて実現することを構想し、その中核技術としてEJB（Enterprise JavaBeans）を据えた。EJBを使うと、ネットワーク越しにJavaのオブジェクトが通信し合い、データベースへの永続化も含めてエレガントに処理できるはずだった。Sun Microsystemsの制定したJava EE仕様を実装するアプリケーションサーバ製品が複数のベンダーから出荷され、活況を呈した。 -3. だが、実際のJava EEアプリケーションサーバ製品は不安定で性能も悪く、プログラミングも難しいものであった。人々はJava EEを信じて使い続けていたが、疑問も大きく膨らんでいった。 -4. そこに登場したのがSpring Frameworkだった（2002年頃）。 +1. Sun Microsystemsはサーブレットの成功に気を良くして、これを一層強力に推進してエンタープライズの世界を支配しようと試みた。そうして出てきたのはJava EE（Enterprise Edition）だった +2. Java EEは、エンタープライズアプリケーションを多数のサーバの連携する分散処理を通じて実現することを構想し、その中核技術としてEJB（Enterprise JavaBeans）を据えた。EJBを使うと、ネットワーク越しにJavaのオブジェクトが通信し合い、データベースへの永続化も含めてエレガントに処理できるはずだった。Sun Microsystemsの制定したJava EE仕様を実装するアプリケーションサーバ製品が複数のベンダーから出荷され、活況を呈した +3. だが、実際のJava EEアプリケーションサーバ製品は不安定で性能も悪く、プログラミングも難しいものであった。人々はJava EEを信じて使い続けていたが、疑問も大きく膨らんでいった +4. そこに登場したのがSpring Framework（2002年頃） - 作者のRod JohnsonがExpertt One-on-One J2EE Design and Developmentとともに世に問うたもの。 - - Java EE（J2EE) の欠点を指摘し、EJB、とりわけ`Entity Beans`を使うことは断念し、POJO（Plain Old Java Object) をベースに開発することを提唱した。 + - Java EE（J2EE) の欠点を指摘し、EJB、とりわけ`Entity Beans`を使うことは断念し、POJO（Plain Old Java Object) をベースに開発することを提唱した - DI （Dependency Injecttion) のアイデアを普及させ、大規模なJavaアプリケーションを効率よく分業体制で実装する道を切り開いた。 5. Spring Frameworkは一世を風靡しただけでなく、今日まで人気を失うことなく、利用されている。 - StrutsはStrus1の後継バージョンであるStruts2が、Struts1とまったく互換性がなかったため、Struts1を採用していた開発会社に受け入れられなかった。 - - その後脆弱性問題を連発したため、今日ではまったく人気がない。 + - その後脆弱性問題を連発したため、今日ではまったく人気がない ### Ruby on Rails @@ -237,11 +249,11 @@ end - PHP: CakePHP - Java: JBoss Seam, Java EE 6, Grails（Groovyを使う) - Python: Django -1. 今でも第一線で使われており、githubもRailsで作られ続けている。一方で一時期より採用されることは減ってきた。 +1. 今でも第一線で使われており、githubもRailsで作られ続けている。とはいえ一時期より採用されることは減ってきた。 - 「マイクロサービス」が注目され、小さなアプリケーションを多く作るようになった - Railsはどちらかというと大きなアプリを作るためのフレームワークであり、マイクロサービスと対比してモノリスアプリの例として扱われる - とはいえ最近はまた一巡してモジュラーモノリスなど大きなアプリが着目されており、流れが変わりつつあるかもしれない - - pythonが言語として人気であり、その流れでDjangoが採用されることが増えた（？） + - pythonが言語として人気であり、その流れでDjangoが採用されることが多い（？） - Goなどに比べてパフォーマンス面で不利 ```bash @@ -262,13 +274,13 @@ Person.create(email: 'hoge@example.com', username: 'hoge') # データの作成 ### Ajaxの出現 / フロントエンド+APIサーバの時代 -1. Google MapsおよびGmailの出現により、「画面遷移を伴わないWebアプリケーション」というものがユーザーに認知され始めた。2005年ごろのことである。 -2. Googleのエンジニアたちの使った技法は、技術としてはそれ以前から存在していたが誰も注目してこなかったXMLHttpRequestというJavaScriptの機能を初めて本格的に使用するものだった。 +1. Google MapsおよびGmailの出現により、「画面遷移を伴わないWebアプリケーション」というものがユーザーに認知され始めた。2005年ごろのこと +2. 技術としてはそれ以前から存在していたが誰も注目してこなかったXMLHttpRequestというJavaScriptの機能を初めて本格的に使用するもの 1. この技法をAsynchronous JavaScript + XMLの頭文字をとってAjax （エイジャックス) と呼ぶようになった。 3. StrutsやRuby on Railsはサーバサイド（バックエンド）側でリクエストを処理して画面も生成するというようなスタイルが中心だった。しかしAjaxが人気を集めるようになるとクライアント（フロントエンド）側で画面描画をすべて行い、バックエンドにはAPIサーバのみを置くというスタイルが人気を集めるようになった。 - 1. 画面遷移を伴わないWebアプリケーションのことをSPA （Single Page Application) などと呼ぶ。 - 2. このスタイルが定着すると、デスクトップアプリケーションと比較しても遜色ないUIのWebアプリケーションが当たり前のように期待されるようになっていった。 - 3. 要求の高度化に応えるため、フロントエンド側のフレームワークが非常に速いペースで開発されているのが今日の状況である。今日、人気のあるフロントエンド・フレームワークとしてReact （Facebook)、Angular （Google)、Vue.js （Evan You)などがある。 + 1. 画面遷移を伴わないWebアプリケーションのことをSPA （Single Page Application) などと呼ぶ + 2. このスタイルが定着すると、デスクトップアプリケーションと比較しても遜色ないUIのWebアプリケーションが当たり前のように期待されるようになっていった + 3. 要求の高度化に応えるため、フロントエンド側のフレームワークが非常に速いペースで開発されているのが今日の状況である。人気の出たフロントエンド・フレームワークとしてはReact （Facebook)、Angular （Google)、Vue.js （Evan You)などがある ### Node.js @@ -339,12 +351,22 @@ RubyやPython、Javaなどのように実行環境をインストールする必 - コンパイル言語なので（スクリプト言語に比べると）デバッグが難しい - Railsのようなフレームワークに頼らず、自力でアプリケーションを構築していく必要がある -### その先... +### SSR(Server Side Rendering)の隆盛 + +- 前述の通りSPAが流行り、画面描画全てJavaScriptで実装するサイトが増えた +- しかしSPAサイトは静的なHTMLとしてみるとJavaScriptしかなく何が書いてあるサイトなのか分からないため、Google検索などの検索サイト対策では不利だった +- またJavaScriptの実行に時間がかかる分最初に真っ白な画面が表示されるなど、ユーザビリティの問題も指摘されるように +- そこであらかじめサーバサイドでWebサイトをレンダリングし、ブラウザでは一部の動的コンテンツのみを描画するスタイルが注目されている +- RailsやCGIとの違いとしては、Next.js(react)やVueなどのSPA用フレームワークによるSSRサポートが強力で、SSRと動的部分を同じコードベースで実装できる点がある + - Railsで同じようなことをしようとすると、SSR部分はRailsで、動的部分はReactで・・・というように実装が複雑になりがち + - この場合サーバサイドの実行環境としてNode.jsが必要になる + +### その他... - Haskellなどの関数型言語が流行りそう？ -- Rustはいい言語だが書くのが難しく、どちらかというとOSなどのシステムプログラミング向け +- Rustはいい言語だが書くのが難しく、どちらかというとOSなどのシステムプログラミング向け（と思ってる） - Rustのメモリ管理はGC（ガベージコレクト）を起こさないためのもの - - Webアプリの実行環境はある程度メモリやCPUを富豪的に使えるため、書きやすさを優先してGoやRuby, JavaなどGCのある言語が使われる傾向にある + - Webアプリの実行環境はある程度メモリやCPUを富豪的に使えるため、書きやすさを優先してGoやRuby, JavaなどGCのある言語が使われる傾向にある？ ## アプリケーションプログラミングインタフェース(API) の色々