2

個人的なサイトは主にブログ、ギャラリーコンポーネント、コードスニペット、デモがあります。GAEは合理的な規模のウェブサイト(個人サイトなど)の無料ホスティングを提供するため、GAEを選択しました。GAE WebappまたはDjango-nonrel?

私は当初、Djangoのアプリケーションを変更せずにホストできると思っていました。私はDjangoでいくつかの経験があるので、簡単にサイトを展開することができます。しかし、さらなる研究の結果、私はこれが当てはまらず、GAEのDjangoサイトをホストするためにいくつかの "ハック"が必要であることを発見しました。

また、Webアプリケーションのいくつかの実装を見ている時に、GAEはおそらくドキュメントがあることを、それを作ったとして困難な多く単純ではないようです。だから私の質問は、これらはhttps://github.com/ccarpenterg/todolist/wiki

  • GAE WebappでDjangoを使用することに利点はありますか?
  • オーバーヘッドコストに見合ったメリットがありますか?
  • GAE Webappsの学習曲線はごくわずかで、Djangoアプリよりも実装が簡単だろうと思いますか?

答えて

7

Webアプリケーション上ではDjangoを使用するには、いくつかの理由があります:

  • ポータビリティは - 汎用フレームワークを使用するには、それが簡単にApp Engineと従来のホスティング・プロバイダー間の既存のアプリを移動することができます。
  • 特長 - Djangoは、より強烈なフレームワークであり、より多くの鐘と笛を出します。

しかし、欠点は、あなたが2番目のクラスの市民だということです。ほとんどのDjangoユーザーはSQLバックエンドを使って作業しています。ほとんどのApp Engineユーザーはwebappを使用しています。フレームワークとプラットフォームが整列しない場所は、両方の開発者にとってあまり重要ではないでしょう。

Djangoを使用する魅力的な理由がない限り、私はwebappに固執します。

+0

その答えをありがとう。私はちょうどFlask(リンク(http://flask.pocoo.org/))を発見しました。それは良い妥協であるようです。しかしおそらく、別の質問のために保存されているのがベストでしょう。 – sw00

+0

webappとyour-framework-of-choiceについては、http://stackoverflow.com/questions/6774371/flask-vs-webapp2-for-google-app-engine/6786745#6786745を参照してください。「第二種市民ドリューの答えの一部。 – moraes

0

GAEウェブアプリケーションは「学習曲線が無視できる」とは言えません。私はそれをWebアプリケーションのための優れたプラットフォームと見なしてきましたが、従来のCGI + SQLプラットフォームとはかなり異なるいくつかの側面を持っています。

他のプロバイダと同じようにAppEngineで動作するアプリケーションをハックすることは可能でしょうが、複雑さ、重要な詳細や相違点、AppEngineを特別にする詳細を学ぶことは簡単なことではありません。

+0

当然のことながら、細かいことやトリックを学ぶのにはかなり時間がかかりますが、[リンク](https://github.com/ccarpenterg/todolist/blob/master/main.py)で判断すると、コグニティブオーバーヘッドとコードラインが少なくなり、ウェブサイトを稼働させることができます。つまり、私は、バックエンドよりも、デザイン/テンプレート側にもっと集中することができます。しかし、いつものようにトレードオフがあるので、私はそのトレードオフが実際に何であるか疑問に思います。 – sw00

2

開発中に私はdjango non-relからgaeモデルを使用しましたが、djangoテンプレート(およびテンプレートタグ)は保持していました。

私にとっては、取引停止者は現在、非現行取引は取引をサポートしていないということでした。効率を上げるためにトランザクションを最小限に抑える必要がありますが、(特にユーザーのアカウント残高を減らす場合は)便利なことがあります。

私は私が実際にデータストアを全く理解していないことに気づいた。それは、私が非relが隠れていたものを見たのはそれを直接使った後でした。これは、いったんnon-relがトランザクションをサポートすると(彼らは今働いている、私は信じている)私は戻っていないだろうが、私はしばらくの間、Googleのクラスを直接使用したことがうれしいです。

私は少なくとも、オブジェクトとトランザクションのツリーを含む「生の」ストアでいくつかの小さな実験を試してみることをお勧めします。データストアをよく理解したら、適切であればnon-relを使用することを検討してください(移植性は否定できない利点であるため)。

私はdjangoのテンプレートとテンプレートタグを、urlディスパッチプロセスと一般的な設定と共に保存しました。私はgaeフレームワークを見ましたが、djangoが与えるものほど強力ではありませんでした(たとえば、djangoの名前付きURLパターンはかなり素晴らしいです)。

tl; dr:私は非relを残してうれしかったですが、djangoにとどまっていました。それは私のために働いたが、私は将来、non-relに戻ることを検討するだろう。

+0

完全に同意します。私はフラスコと同じ問題を抱えていた。 Webappを直接使用して、すべてのことを知る必要があります。 – qliq

関連する問題