126

非常に小さくて手っ取り早いサイド プロジェクトを探しています。Google App Engine が Django が組み込まれた Python で実行されているという事実が気に入っています。そのプラットフォームを試す口実になりますが、私の質問は次のとおりです。

おもちゃの問題以外でアプリエンジンを利用した人はいますか? 良い例のアプリがいくつかあるので、実際の取引にはこれで十分だと思いますが、フィードバックが必要でした.

他の成功/失敗のメモは素晴らしいでしょう。

4

11 に答える 11

63

小さな地震監視アプリケーションhttp://quakewatch.appspot.com/のアプリ エンジンを試しました。

私の目的はアプリ エンジンの機能を確認することだったので、主なポイントは次のとおりです。

  1. Djangoにはデフォルトで付属していません.Pythonicの独自のWebフレームワークがあります.DjangoのようなURLディスパッチャーがあり、Djangoテンプレートを使用しています.Django exp. 使いやすいでしょう
  2. サーバー上で長時間実行されるプロセスを実行することはできません。リクエストに応答する必要があります。そうしないと、appengine がそれを強制終了します。したがって、アプリが多くのバックエンド処理を必要とする場合、appengine は最適な方法ではありません。独自のサーバーで
  3. 私の地震監視アプリにはサブスクリプション機能があります。つまり、最新の地震が発生したときに電子メールで送信する必要がありましたが、アプリ エンジンでバックグラウンド プロセスを実行して新しい地震の解決策を監視することはできません。あなたのページの1つに接続し、サブスクリプションメーラーを実行しますが、ここでも多くの時間を費やしたり、タスクをいくつかの部分に分割したりしないように注意する必要があります
  4. Django のようなモデリング機能を提供しますが、バックエンドはまったく異なりますが、新しいプロジェクトでは問題になりません。

しかし、全体として、バックグラウンド処理をあまり必要としないアプリを作成するには優れていると思います。

編集：バッチ処理またはスケジュールされたタスクの実行にタスクキューを使用できるようになりました

編集：GAEで実際のアプリケーションを1年間作業/作成した後、私の意見は、何百万人ものユーザーにスケーリングする必要があるアプリケーションを作成していない限り、GAEを使用しないことです。GAE で簡単なタスクを維持して実行することは、分散された性質のために頭痛の種です。締め切り超過エラーを回避したり、エンティティをカウントしたり、複雑なクエリを実行したりするためには複雑なコードが必要になるため、小さくて複雑なアプリケーションは LAMP に固執する必要があります。

編集: モデルは、将来必要とするすべてのトランザクションを考慮して特別に設計する必要があります。これは、同じエンティティ グループ内のエンティティのみがトランザクションで使用でき、2 つの異なるグループを更新するプロセスが悪夢になるためです (例: user1 から user2 への送金)。 in transaction は、それらが同じエンティティ グループに属していない限り不可能ですが、同じエンティティ グループにすることは、頻繁な更新の目的には最適ではない可能性があります.... このhttp://blog.notdot.net/2009/9/Distributed-Transactions-を読んでください。 on-App Engine

于 2008-09-21T04:52:12.543 に答える
36

GAE を使用して、トラフィックの多いアプリケーションをいくつかホストしています。50 ～ 100 リクエスト/秒程度です。それは素晴らしいです、私はそれを十分にお勧めできません。

以前の Web 開発の経験は Ruby (Rails/Merb) でした。Python を学ぶのは簡単でした。私は Django や Pylons、その他のフレームワークをいじりませんでした。GAE の例から始めて、提供されている基本的な webapp ライブラリから必要なものを構築しました。

SQL の柔軟性に慣れている場合は、データストアに慣れるまでに時間がかかることがあります。あまりにもトラウマ的なものはありません！最大の調整は、JOIN から離れることです。正規化が重要であるという考えを捨てる必要があります。

ベン

于 2009-02-19T18:08:15.153 に答える
23

私が Google App Engine を使用する理由の 1 つは、ドメインの Google Apps との統合です。基本的に、ドメインの (制御された) ログインに制限されたカスタムのマネージド Web アプリケーションを作成できます。

このコードに関する私の経験のほとんどは、単純な時間/タスク追跡アプリケーションを構築することでした。テンプレート エンジンはシンプルでありながら、複数ページのアプリケーションを非常に親しみやすいものにしました。ログイン/ユーザー認識 API も同様に便利です。あまり問題なく公開ページ/非公開ページのパラダイムを作成できました。(ユーザーはログインして非公開ページを表示します。匿名ユーザーには公開ページのみが表示されました。)

「実際の作業」のために引き離されたとき、私はプロジェクトのデータストア部分に取り掛かったところです。

私は非常に短い時間で多くのことを達成することができました (まだ完了していません)。私は以前に Python を使用したことがなかったので、これは特に快適でした (これは私にとって新しい言語であったことと、新しい言語にもかかわらず開発が高速であったことの両方の理由からです)。私は自分の仕事を達成することができないだろうと信じるに至ったものはほとんどありませんでした. 代わりに、私は機能と機能についてかなり肯定的な印象を持っています.

それが私の経験です。おそらく、それは未完成のおもちゃのプロジェクト以上のものを表すものではありませんが、プラットフォームの十分な情報に基づいた試行を表すものであり、それが役立つことを願っています.

于 2008-09-21T05:12:25.257 に答える
12

「Django を実行する App Engine」という考えは、少し誤解を招きます。App Engine は Django モデル レイヤ全体を置き換えるため、App Engine のデータストアに慣れるために時間を費やす準備をしてください。App Engine のデータストアには、データのモデリングと考え方に異なる方法が必要です。

于 2008-09-21T04:09:00.323 に答える
7

私はGAEを使用してhttp://www.muspy.comを構築しました

それはおもちゃのプロジェクトよりも少し多いですが、過度に複雑でもありません。私はまだグーグルが取り組むべきいくつかの問題に依存していますが、ウェブサイトの全体的な開発は楽しい経験でした。

ホスティングの問題やサーバー管理などに対処したくない場合は、絶対にお勧めします。特にPythonとDjangoをすでに知っている場合。

于 2008-09-23T02:37:29.683 に答える
7

現時点では、App Engine は小さなプロジェクトにはかなり優れていると思います。ホスティングについて心配する必要がないことについては、多くのことが言えます。API は、スケーラブルなアプリを構築する方向にもあなたを後押しします。これは良い習慣です。

  • app-engine-patchは、Django と App Engine の間の優れたレイヤーであり、認証アプリなどの使用を可能にします。
  • Google は、2008 年末までに SLA と価格モデルを約束しました。
  • リクエストは 10 秒で完了する必要があり、Web サービスへのサブリクエストは 5 秒で完了する必要があります。これにより、高速で軽量なアプリケーションを設計し、重要な処理を他のプラットフォーム (ホストされたサービスや EC2 インスタンスなど) にオフロードする必要があります。
  • より多くの言語が間もなく登場します！ただし、Googleはどちらを言うことはありません:-)。私のお金は次の Java にあります。
于 2008-10-08T16:28:00.950 に答える
6

この質問は完全に回答されています。どっちがいい。しかし、おそらく言及する価値があることが 1 つあります。Google アプリ エンジンには、Eclipse ide 用のプラグインがあり、これを使用すると楽しく作業できます。

すでに Eclipse で開発を行っている場合は、それについてとても満足するでしょう。

Google App Engine の Web サイトにデプロイするには、飛行機のロゴが付いた小さなボタンを 1 つクリックするだけです。

于 2010-03-17T12:52:04.343 に答える
4

SQL ゲームを見てみましょう。これは非常に安定しており、実際にある時点でトラフィック制限を押し上げたため、Google によって抑制されていました。他の誰かが完全に制御するサーバーでアプリをホストすること以外に、App Engine について良いニュースしか見たことはありません。

于 2008-09-21T03:47:36.787 に答える
4

GAE を使用して、いくつかのパラメーター、フォーマットを受け取り、電子メールを送信する単純なアプリケーションを作成しました。非常にシンプルで高速でした。また、GAE データストアと memcache サービス ( http://dbaspects.blogspot.com/2010/01/memcache-vs-datastore-on-google-app.html ) のパフォーマンス ベンチマークも作成しました。それほど速くはありません。私の意見では、GAE は特定の方法論を強制する本格的なプラットフォームです。悪い慣行が許されない真にスケーラブルなプラットフォームに進化すると思います。

于 2010-01-28T15:20:56.617 に答える
4

フラッシュ ゲーム サイトのBearded Games でGAE を使用しました。GAE は優れたプラットフォームです。以前の PHP よりもはるかに簡単な Django テンプレートを使用しました。優れた管理パネルが付属しており、非常に優れたログを提供します. データストアは MySQL などのデータベースとは異なりますが、操作ははるかに簡単です。サイトの構築は簡単で簡単で、サイトに関する有益なアドバイスがたくさんあります.

于 2010-02-18T21:58:33.780 に答える
3

私は GAE と Django を使用して Facebook アプリケーションを作成しました。Django 1.1 をサポートしているため、出発点としてhttp://code.google.com/p/app-engine-patchを使用しました。manage.py コマンドは機能しないと思っていたので、使用しようとはしませんでしたが、調べることさえしませんでした。アプリケーションには 3 つのモデルがあり、pyfacebook も使用されていましたが、複雑さはそれだけでした。私は、http://brianyamabe.comでブログを書き始めている、はるかに複雑なアプリケーションを作成中です。

于 2009-09-10T18:21:41.670 に答える