Phoenix Framework を使用してリアルタイムWeb/モバイル アプリを楽しく構築する方法を学びましょう
それは「エンドユーザー」にとって高速で、信頼性が高く、スケーラブルで、保守可能で、 (簡単に)拡張可能です。
Web/モバイルアプリ開発者として、私たちは他の(本当に賢い)人々が行った仕事を活用する必要があります
常に「ゼロから」物事を構築し続けるのではなく、それが、アプリを構築するためにフレームワークを使用する理由です。
参照: 「フェニックスを選ぶ理由トップ 10 」 (このページのさらに下にあります! )
選択できるフレームワークは数多くあります (いくつかの「人気のある」フレームワークについては、以下の「質問」セクションで説明します)。
しかし、もし私たちが「人気」に従っているなら、私たちは依然としてどこでも馬(および荷車)に乗っていることになり、進歩はありません。
注: Elixirのすべての「なぜ」の理由はPhoenixにも当てはまります。
チェックしてください: https://github.com/dwyl/learn-elixir#why
妥協のないWebアプリケーションフレームワーク!
あらゆるテクノロジープロジェクトにおける最大の「制約」は人材です。 「起業家」/「創業者」または「プロダクトオーナー」は、世界中のあらゆる優れたアイデアを持っていても、アイデアを現実に変えることができなければ意味がありません。
明らかに、独自のハードウェア/クラウドで独自のベンチマークを実行し、アプリ/製品の要件に基づいて情報に基づいた決定を下す必要がありますが、...Phoenix アプリが処理できる同時ユーザー数の統計を読むと (ライブでWebSocket 接続)びっくりしました!これは、90% 少ないリソースでリアルタイム アプリを構築できることを意味します。
これらすべては、ハードウェア/クラウド インフラストラクチャに費やす費用が大幅に削減され、アプリ/企業がコスト面で競争上の優位性を獲得できることを意味します。
幸運なことに、次のプロジェクトでより優れたものを使用することを検討している場合は、Phoenix 以外に探す必要はありません。
詳細はこちら: http://www.phoenixframework.org
多くの人々/チーム/企業がすでにErlang/Elixir と Phoenix を使用しており、驚異的な結果を得ています。
含まれるもの: Adobe、BBC、Spotify、Pinterest、Discord (ゲーマー チャット アプリ)、Groupon (Fave)、Lonely Planet、Brightcove、Slack ...
参照: https://github.com/doomspork/elixir-companies
Elixir を知らなければ Phoenix アプリを構築することはできません。
Elixir を初めて使用する場合は、 this
リポジトリに「スター」 (ブックマーク) を付けてください (明日このリポジトリに戻れるようになります)
そして、github.com/dwyl/ learn-elixirにアクセスして、構文を理解したと感じるまで elixir を学習してから、戻ってきて Phoenix を学習してください。
具体的には、 Elixir の「基礎」の学習に重点を置く必要があります。
Phoenix は Node.js を使用して、JavaScript や CSS ファイルなどのアセットをコンパイルします (Webpackを使用)。
Node.jsがインストールされていることを確認するだけです。 https://nodejs.org
Phoenix を使用するために Node を知る必要はありません。
すでに Elixir を学習し、Node.js をインストールしている場合は、Phoenix を使い始めるための最初のステップはインストールです。
Phoenix のドキュメントは素晴らしいので、公式の Phoenix インストール手順に従うことをお勧めします。
PostgreSQL もインストールする必要があります。その方法については、上にリンクされている Phoenix インストール ガイドにリンクされていますが、 learn-postgresql
リポジトリで手順を確認し、問題がある場合は問題を提起することもできます。 !
JavaScript の基本を理解していると役立つ場合もありますが、Phoenix を使用するために Node の使用方法を知る必要はありません。
なぜ彼らが「代替手段」ではなく Brunch.io を選んだのか興味があるなら、
簡単に言うと、「シンプルさとスピード」です。参照: http://brunch.io/docs/why-brunch
注: Phoenix v1.4 (執筆時点では未リリース) はアセットのコンパイルに WebPack を使用します。CHANGELOG.md を参照してください。
「稼働中」(公式) ガイドをよく理解してください: https://hexdocs.pm/phoenix/up_and_running.html#content
phoenix をインストールし、公式の「稼働中」ガイドに従っていれば、
戻って、これらの初心者向けの例を試してみてください。
@chrismccord の本「Programming Phoenix」を購入する(または借りる) ことをお勧めします。
参照: https://pragprog.com/book/phoenix14/programming-phoenix-1-4
著者たちは個々に印象的であり、集合的に他の誰にもできないようにフェニックスを包括的にカバーしています。 Chris は Phoenix を作成し、José は Elixir を作成しました。そして Bruce は、数多くの成功した著書を持つ非常に経験豊富な技術作家です。
(つまり、フェニックスを学ぶにはこの本が最適です! )
https://youtu.be/MD3P7Qan3pw
https://youtu.be/srtMWzyqdp8
「 Phoenix はRuby-on-Rails の生産性を提供します」
Erlangの同時実行性と耐障害性を備えています。」
Phoenix はElixirプログラミング言語を使用します。これは、アプリがコンパイルされ、 Erlang 仮想マシン「BEAM」上で実行されることを意味します。
Erlang は、多くの通信会社で使用されている、厳しいテストを経た耐障害性の高い VM です
WebSocket (「チャネル」) はフレームワークに組み込まれているため、「リアルタイム」通信とインタラクションを備えたアプリの構築が、事実上他のどのフレームワーク/プラットフォームよりもはるかに簡単になります。 (サードパーティ製のmagic
モジュールは必要ありません。必要なものはすべてすでに用意されており、何百万人もの人々にサービスを提供する準備ができています!! )
参照: http://www.phoenixframework.org/docs/channels
Phoenix ( Elixir ) のすべてのプログラミングはFunctionalであるため、非同期性が容易です。これは、リクエスト認証、ロギング、人間が容易に判読できる「パイプライン」への処理などの便利な機能を抽象化することが非常に簡単であることを意味します。 (サードパーティのasync
モジュールは必要ありません。「プロミス」、「ジェネレーター」、または「オブザーバブル」を管理する必要はありません!! )
セキュリティと回復力の考え方がdefault
です。 Phoenix/Elixir では暗号化(SSL) が簡単で、 SQL インジェクションの緩和、クロスサイト スクリプティング( XSS )、およびCSRF 保護の両方が組み込まれている( default
で有効になっている) ため、「初心者」プログラマがこのタイプを導入することは事実上不可能です。セキュリティバグのこと。
簡潔なコードを軽視することはできません。同等のNode.js/Java/Rails/Go アプリよりもはるかに少ない行を記述できます。これは、開発者の生産性が向上し、保守するコードが少なくなることを意味します。
すべてのコントローラーの関数プログラミングによるテスト容易性!
簡単な導入: https://hexdocs.pm/phoenix/heroku.html
ゼロダウンタイムの導入は無料です! (これも Erlang のせいです)。 Erlang は、「ライブ/アクティブ」ユーザーがアップグレード/更新されたことに気付かずに、アプリの古いバージョンから新しいバージョンへの移行を管理します。
Erlang スーパーバイザーによるアプリの組み込みの監視/管理により、アプリのパフォーマンス、どの部分がクラッシュ/再起動したか、そしてその理由を正確に把握できるようになります。これは、他のフレームワークでは (多額の)支払いを行っている機能ですが、ここでは無料です。
Phoenix を使用することが素晴らしい理由が他に思い当たりますか?!
このスレッドでご意見を共有してください: #13
before
Elixirを学ぶ必要がありますか?はい。参照: https://github.com/dwyl/learn-elixir
いいえ。今すぐElixir の学習/使用を開始し、必要に応じて Erlang 関数を呼び出すことができます。
ただし、Phoenix を使用するbefore
Erlang を知る必要はありません。
あなた/私たちが選択できる Web アプリケーション フレームワークは数多くあります: https://en.wikipedia.org/wiki/Comparison_of_web_frameworks
では、なぜ「主流」ではないプログラミング言語で書かれたフレームワークを選択するのでしょうか...?
これは誤った情報です。私たちは今でも、適切な場合には、多くのプロジェクトで Hapi.js を使用しています。
これには、いくつかのクライアント プロジェクトと内部の dwyl アプリ/ツールが含まれます。
私たちは次のような単純な理由から、新しいプロジェクトに Phoenix を使用することにしました。
#LessIsMore
#LessButBetter
#SmallIsBeautiful
#SyntaxMatters
新しいプロジェクトには、マルチデータセンターのフォールトトレランスが必要です。
Erlang -> Elixir -> Phoenix を使用することで、「無料」でそれを取得できます。
私たちの意見では、Hapi.js は依然として「最高の」Node.js フレームワークであり、 continue
使用し、推奨していきます。
拡張性があり、保守が簡単なシンプルなアプリを必要とする人々に最適です。
参照: https://github.com/dwyl/learn-hapi
また、すべての AWS Lambda マイクロサービスで JavaScript を引き続き使用しており、それは今後も変わりません。
シンプルで効率的で、拡張性も非常に優れています。
参照: https://github.com/dwyl/learn-aws-lambda
オリジナルの「生産的な」Web フレームワークは、2005 年当時の「Ruby-on-Rails」と「Django」( Python ) でした。
(私たちは「旅」の中でこれらの両方を一定期間使用したので、それぞれの利点について話すことができます。)
Rails や Django を使用することに「何も問題はありません」。
両方のフレームワークにはまだ多くのユースケースがあると考えています。
私たちが知っているのは、「リアルタイム」を構築する方が (はるかに)簡単であるということだけです。
Phoenix では「チャネル」( WebSocket ) が組み込まれているため、
そして、Elixir/Erlang の同時実行はまったく異なるボールゲームです。
Erlang (したがって Phoenix) は単一サーバー上で何百万もの同時ユーザーを処理できます。
一方、Rails/Django サーバーは数千 (よくても!) しか処理できません。
アプリが一度に数千人にしかサービスを提供しない場合は、問題ありません。
私たちは、Erlang が「軽量で長寿命」プロセスを使用しているという事実を気に入っています。
これは、何百万もの ( IoT ) デバイスを接続できることを意味します...IoT にとって Erlang が (疑いなく) 答えです。
1 日に数人のユーザーのみが予想される単純な Web アプリの場合は、Rails/Django が依然として有効です。
しかし、その必要がないのになぜ妥協するのでしょうか?
フォード フォーカスの「価格」でテスラが買えるなら、なぜ買わないのでしょうか?!
最高のものを簡単に手に入れたり使用したりできるのに、なぜ永久に満足するのでしょうか?
はい、GitHub は依然として Web アプリ/サイトに Rails を使用しています。
ただし、GitHub のコアチームの誰かに、(やり直すチャンスがあれば) Rails を選ぶかどうか尋ねてください。
2017 年に GitHub を構築して、そのうちの何人が「はい、もちろんです」(真顔で… ) と言うか見てみましょう!
また、GitHub はバックグラウンドで Rails をスケールするために多くのことを行います。
そして、新しい(クライアント側) 機能の多くはJavaScript で書かれています。参照: https://github.com/github
結論は、「DevOps」を使用すると、あらゆるものを拡張できるということです。
しかし、 Phoenix はdefault
でスケールするように作られています。これは、Erlang がスケールするように発明されたためです。
「プログラミング言語には 2 種類あります。誰も使わない言語と、誰もが愚痴っている言語です。」 ~ ビャルネ・ストロイストラップ (
C++
の作成者)
囲碁はとても人気があります。これは主に、Google が「スポンサー」であるという事実によるものです。
これは、Google 内のC++
と Java を簡素化 (置き換え) することを目的としていました...
そしてほとんどの場合、それは成功しました!
私たちは碁が大好きです。どのプログラミング言語を選ぶかを決めるとき、それが「第 2 位」の選択でした。
( Elixir の後) 「ポスト JS スタック」内... else
ではなくelixir
使用するという決定は簡単でした。
さらに読む:
Play
Framework を使用してみてはいかがでしょうか...? Java の作成や JVM へのデプロイにすでに慣れている場合は、Play Framework が最適な選択肢です: https://www.playframework.com
Scala は優れたプログラミング言語なので、誰もが学ぶべきです。 https://www.scala-lang.org/what-is-scala.html
私たちは Play を数回 ( Node.js を採用する前に) 使用しましたが、とても気に入りました。
しかし、Scala は、人々が「 Java のすべて」を使用できるようにする「キッチンシンク」 (マルチパラダイム) プログラミング言語です。
Scala の「Java 相互運用性」は、コードベースに複雑さを取り入れることが「簡単すぎる」ことを意味すると考えています。具体的には「OOP変異」…
では、なぜ私たち (DWYL) は新しいプロジェクトに「Play」をもう使わないのでしょうか?まず、数年前に Hapi.js ( Node.js ) に移行しました。その理由は、Hapi.js のほうが「軽量」であり、RAM を数メガしか使用しない小さなプログラムを作成できるためです ( Play アプリはリソースを大量に消費していました)。 .! Chromebook のような「基本的な」ラップトップで Scala アプリを実行したことがありますか?
Play ではなく Phoenix を採用する「理由」の概要:
私たちのプロジェクトでは、 Erlang の同時実行モデルがより適切に機能し、不変データを変換する関数コードの方がテストと保守が簡単であると考えています。
「 Scala のほうがシンプルである」という証拠をお持ちでしたら、ぜひご連絡ください。
教えてください: https://github.com/dwyl/learn-phoenix-web-development/issues
関数型プログラミング( FP ) がそんなに好きなら、Haskell を使ってみてはいかがでしょうか?