2017年にGo Webアプリを構築する

数週間前、私はもうGoでのみ別のWebアプリケーションの開発を始めました。 主にバックエンド開発者であるため、Webアプリケーション全体を作成することはあまりなかったので、そのようなケースはそれぞれ挑戦のようでした。 そのような瞬間に、優れたデザインの複雑さを一日中掘り下げる機会はないが、大騒ぎせずに機能する機能的なウェブサイトを作成するだけの人のために、ウェブ開発ガイドを書いてほしい。

私はこの機会を利用して、2017年に行われるべき方法でWebアプリケーションをゼロから始めるためのガイドを作成することにしました（私の理解では）。 以前は避けていたものを掘り下げるのに何時間も費やしましたが、それは長年に少なくとも一度は、この問題について自分の意見と経験を持っていると自信を持って言えるようになり、自分のための実用的なレシピを手に入れることができたからです、これは私だけでなく役に立つかもしれません。

この記事は、私がその過程で学んだことをカバーする短いシリーズから始まります。 この最初の投稿は、現状、問題、およびGoが適切な選択肢であると考える理由を説明する一般的な紹介です。 後続の記事はより詳細になり、より多くのコードが含まれます。 私の経験があなたの経験とどの程度相関しているか興味があります。 多分私は何かについて間違っているので、コメントしてください。

コードにのみ興味がある場合は、 こちらにあります 。

はじめに

以前は、HTML、CSS、およびJavaScriptについての基本的な知識で、Webサイトの作成に必要な最低限の要件を満たしていました。 私がこれまでに作成したほとんどのアプリケーションは、ハンドラー公開メカニズムを直接使用してmod_pythonを使用して作成されました（例：例はこちらを参照してください ）。 Pythonの初期のフォロワーとして、私もRailsで多くの仕事をしたことは面白いです。 ここ数年、私は（大きな）データインフラストラクチャに焦点を当ててきましたが、これはWeb開発ではありませんが、ここでWebインターフェイスが必要になることは珍しくありません。 実際、私が現在取り組んでいるアプリケーションはデータアプリケーションですが、それはオープンソースではなく、この記事とは無関係です。 一般に、これは私がこれをすべて見ている側を明確にする必要があります。

PythonとRuby

1年前は、Webアプリケーション環境としてPythonまたはRubyをお勧めします。 他の同様の言語もあるかもしれませんが、私の観点からは、PythonとRubyが世界を支配しています。

ほとんどの場合、Webアプリケーションの主なタスクは、サーバー側のHTMLレイアウトを使用してWebページを構築することでした。 PythonとRubyはどちらも、データベースからデータを取得し、テンプレートを使用してHTMLコードの束に変換するのに非常に適しています。 Rails、Django、Sinatra、Flaskなど、多くのフレームワーク/ツールから選択できます。 など

これらの言語にはGILなどの特定の重要な制限がありますが、HTML生成の問題を簡単に解決できることは、妥協するよりもはるかに価値があります。

ギル

GIL（Global Interpreter Lock）は別の言及を伝えます。 もちろん、これはPythonまたはRubyのソリューションの最大の制限ですが、これは非常に滑りやすいトピックであり、多くの場合、人々は問題がないふりをすることを好みます。 そして、これについて話している場合、感情は通常エッジを打ってしまいます。RubyとPythonのコミュニティでは、GILのトピックに関して無限の議論があります。

この問題に慣れていない人のために-GILでは、一度に1つのことしかできません。 スレッドを作成し、それらが並列実行として「見える」場合、実際には、インタープリターはまだ命令を連続して実行します。 つまり、1つのプロセスが使用できるCPUは1つだけです。

JVMに基づく実装など、代替の実装が存在しますが、それらはあまり使用されません。 なぜ完全に互換性がないか、C拡張機能を正しくサポートしていない可能性があり、GILを使用している可能性があります。 私にはわかりませんが、私が知る限り、Cの実装は通常、結局使用されます。GILなしでインタープリターを作成するには、完全に書き換える必要があり、これにより言語の動作が（私の素朴な理解で）既に変更されている可能性があるため、GIL滞在します。

あらゆる規模のWebアプリケーションには、マシンで使用可能な各CPUの機能を使用して、要求を並行して処理する機能が必ず必要です。 これまでのところ、唯一可能な解決策は、アプリケーションの複数のインスタンスを個別のプロセスとして実行することです。

これは通常、Unicorn / Gunicornなどの追加ソフトウェアを使用して行われ、各プロセスは独自のポートでリッスンし、NginxやHaproxyなどの接続バランサーの背後で開始します。 あるいは、これはApacheとそのモジュール（mod_pythonやmod_wsgiなど）を介して行うことができますが、いずれにしても困難です。 このようなアプリケーションは通常、競合するタスクの調停者としてデータベースサーバーに依存しています。 キャッシュを実装する場合、同じサーバーに同じコピーの複数のコピーを保存しないようにするには、MemcachedやRedisなどの共有メモリストアが必要です。通常は両方です。 また、このようなアプリケーションはバックグラウンド処理を実行できません。これには、Resqueなどの別のツールセットがあります。 そして、これらすべてのコンポーネントは、これがすべて機能することを確認するために監視を必要とします。 ログは統合する必要があり、独自の追加ツールがあります。 このセットアップの複雑さは避けられないため、ChefやPuppetなどの構成マネージャーも必要です。 それでも、これらのキットは一般に、多数の長期接続をサポートすることができません-C10Kとして知られる問題です 。

その結果、データベースを備えた単純なWebアプリケーションは、Hello World！ページを提供する前に、大量のコンポーネントを必要とします。 そして、これのほとんどすべてはGILによるものです。

単一ページのアプリケーションの出現

サーバー上でのHTMLの生成は、ますます過去になります。 最後の（そして正しい）傾向は、ユーザーインターフェイスを構築し、JavaScriptを使用してクライアント側で完全にレンダリングすることです。 ユーザーインターフェイスがJSによって完全に制御されるアプリケーションは、 シングルページアプリケーションと呼ばれることもあります。 このようなアプリケーションでは、サーバーはHTMLコードを生成せずに、通常はJSON形式のデータのみを提供します。 この場合、主に人気のあるスクリプト言語を使用して[Webアプリケーションを作成する]可能性のために導入されたそのような非常に複雑な作業は不要です。 特に、すべての出力がJSONである場合、PythonまたはRubyにはほとんどメリットがないことを考慮してください。

Golangを見て

Goは、Webアプリケーションの確立された世界を徐々に侵食しています。 並列実行をネイティブでサポートしているため、GIL制約の処理に一般的に使用されるほとんどすべてのコンポーネントが不要になります。

Goのプログラムはネイティブに起動されるバイナリであるため、サーバーに言語固有のものをインストールする必要はありません。 アプリケーションが必要とする正しいバージョンのランタイムを確保する問題はなくなります。 個別のランタイム環境はありません-バイナリに組み込まれています。 Goプログラムはバックグラウンドで簡単かつエレガントにタスクを実行できるため、Resqueのようなツールは必要ありません。 これらのプログラムは単一のプロセスとして実行されるため、キャッシュは簡単になります。つまり、MemcachedやRedisは必要ありません。 Goは、無制限の数の同時接続を管理でき、Nginxなどのフロントエンド保護の必要性を排除します。

Go、Python、Ruby、Bundler、Virtualenv、Unicorn、WSGI、Resque、Memcached、Redisなどの背の高い多層タワー バイナリを1つに減らしました。 通常必要とされる唯一のサードパーティコンポーネントはデータベースです（PostgreSQLをお勧めします）。 これらのツールはすべて使用できますが、Goがなくても使用できます。

このようなGoプログラムの起動時間は、ほとんどのPython / Rubyアプリケーションよりも桁違いに長くなり、必要なメモリとコード行が少なくなります。

さて、人気のあるフレームワークはありますか？

簡単な答えはこれです。フレームワークはオプションであり、推奨されません。 すばらしいフレームワークであると主張する多くのプロジェクトがありますが、それらなしで行う方が良いと思います。 これは私の個人的な意見であるだけでなく、Goコミュニティではこの意見が非常に一般的だと感じています。

フレームワークが作成された理由を理解する必要があります。 Python / Rubyの世界では、これらの言語はもともとWebページを提供するように設計されておらず、この問題を解決するために多くの外部コンポーネントが必要だったため、これが起こりました。 Javaについても同じことが言えます。Javaは、PythonやRubyのように、ウェブと同じくらい古いか、またはそれより少し古いです。

私が覚えている限りでは、初期のバージョンのPythonはデータベースを操作するための何も提供していませんでした。テンプレートがなく、HTTPサポートが混乱していました。ネットワークでの作業は簡単ではなく、暗号化さえ違法であり、一般に、まだやることがたくさんありました フレームワークはこれらすべての必要な部分を提供し、すべての一般的なWebアプリケーションのバリエーションに対して言語固有の開発ルールを設定しました。

一方、Goは、すでに経験があり、Web開発に精通している人々によって作成されました。 必要なものはほぼすべて含まれています。 OAuthなどの特定の問題を解決するには、1つまたは2つの外部パッケージが必要になる場合がありますが、このペアのパッケージは「フレームワーク」ではありません。

フレームワークに関する上記のすべてが十分に説得力がないと思われる場合は、フレームワークとリスクの学習曲線を考慮することが有用です。 Railsとの関係を築くのに約2年かかりました。 フレームワークは放棄され、時代遅れになる可能性があり、新しいフレームワークへのアプリケーションの移植は難しく、時には不可能です。 情報技術の変化の速さを考えると、フレームワークは確かに軽く選択すべきではありません。

Python、Ruby、またはJavaScript環境に共通のイディオムをシミュレートしようとするツールとフレームワークを強調したいと思います。 リフレクションに大きく依存するインジェクション、メソッドの動的公開などのテクニックを含む、「Rails for Go」の役割に見える、感じる、またはふりをするすべてのものは、Goのイデオロギーに適合しないため、離れて。

フレームワークは、特にビジネス用のCRUDアプリケーションの典型的な世界で、アプリケーションが多くのフィールドを持つ多くのページを持ち、複雑で絶えず変化するデータベーススキームでデータを操作することで、いくつかのことを容易にします。 そのような環境でGoが適切な選択肢であるかどうか、特にパフォーマンスとスケーラビリティが優先事項でない場合はわかりません。

フレームワークに共通する別の問題は、開発者から低レベルのメカニズムを抽象化するため、時間が経つにつれて非常に神秘的になり、実際にそこで何が起こっているのかを理解することが不可能になることです。 JavaScriptの1行の字句エイリアスで始まるものは、サブ依存関係のどこかに隠されたヘルパーの上にあるトランスパイラー、ミニマイザーのレイヤーのレイヤーになります。 何かが壊れると、どこで問題を探すべきかを見つけることができなくなります。 何が起こっているのかを正確に知っていればいいのですが、Goはそれが得意です。

データベースとORMはどうですか？

フレームワークのように、GoのORMはあまり一般的ではありません。 まず、Goはオブジェクトをサポートしていません-略語ORMのOで示されています。

ActiveRecordのようなものによって提供される便利なUser.find(:all).filter...



を使用する代わりに、SQLを手動で記述することは、一部のコミュニティでは前代未聞のことですが、この態度は変わるはずです。 SQLは素晴らしい言語です。 SQLを直接扱うことはそれほど難しくなく、その見返りに、より多くの自由と機会が得られます。 おそらく、この直接的な作業の最も退屈な部分は、データベースカーソルから構造体にデータをコピーすることですが、 sqlxプロジェクトはここで非常に役立ちます 。

おわりに

私の意見では、この記事ではサーバー側の現在の状況について十分に詳しく説明しています。 クライアント部分を別の投稿に分ける方が良いと思うので、今日はそれだけです。 要約すると、おおよそ次の要件でアプリケーションを構築します。

• サードパーティのパッケージへの最小限の依存。
• Webフレームワークなし。
• データベースとしてのPostgreSQL。
• 単一ページのアプリケーション。

継続