I'm developing a web application and considering Django, Google App Engine, and several other options. I wondered what kind of "penalty" I will incur if I develop a complete Django application assuming it runs on a dedicated server, and then later want to migrate it to Google App Engine.
我正在开发一个web应用程序，考虑Django、谷歌应用程序引擎和其他几个选项。我想知道，如果我开发一个完整的Django应用程序(假设它在专用服务器上运行)，然后想要将它迁移到谷歌应用程序引擎上，将会遇到什么样的“惩罚”。
I have a basic understanding of Google's data store, so please assume I will choose a column based database for my "stand-alone" Django application rather than a relational database, so that the schema could remain mostly the same and will not be a major factor.
我对谷歌的数据存储有基本的了解，所以请假设我将为我的“独立”Django应用程序选择一个基于列的数据库，而不是关系数据库，这样模式就可以保持基本不变，而不会成为主要因素。
Also, please assume my application does not maintain a huge amount of data, so that migration of tens of gigabytes is not required. I'm mainly interested in the effects on the code and software architecture.
另外，请假设我的应用程序没有维护大量的数据，因此不需要迁移几十gb。我主要对代码和软件架构的影响感兴趣。
Thanks
谢谢
4 个解决方案
#1
8
Most (all?) of Django is available in GAE, so your main task is to avoid basing your designs around a reliance on anything from Django or the Python standard libraries which is not available on GAE.
Django的大部分(全部?)都在GAE中可用，因此您的主要任务是避免将设计建立在依赖于Django或在GAE上不可用的Python标准库的基础之上。
You've identified the glaring difference, which is the database, so I'll assume you're on top of that. Another difference is the tie-in to Google Accounts and hence that if you want, you can do a fair amount of access control through the app.yaml file rather than in code. You don't have to use any of that, though, so if you don't envisage switching to Google Accounts when you switch to GAE, no problem.
您已经确定了明显的差异，即数据库，因此我假设您已经掌握了这一点。另一个区别是绑定到谷歌帐户，因此，如果您愿意，可以通过app.yaml文件而不是代码进行大量的访问控制。不过，您不需要使用其中的任何一个，因此，如果您不打算在切换到GAE时切换到谷歌帐户，那么没有问题。
I think the differences in the standard libraries can mostly be deduced from the fact that GAE has no I/O and no C-accelerated libraries unless explicitly stated, and my experience so far is that things I've expected to be there, have been there. I don't know Django and haven't used it on GAE (apart from templates), so I can't comment on that.
我认为标准库中的差异主要可以从GAE没有I/O和没有c加速库(除非明确声明)这一事实中推断出来，我的经验是，到目前为止，我所期望的东西已经存在了。我不知道Django，也没有在GAE(除了模板之外)上使用它，所以我不能对此发表评论。
Personally I probably wouldn't target LAMP (where P = Django) with the intention of migrating to GAE later. I'd develop for both together, and try to ensure if possible that the differences are kept to the very top (configuration) and the very bottom (data model). The GAE version doesn't necessarily have to be perfect, as long as you know how to make it perfect should you need it.
我个人可能不会以稍后迁移到GAE为目标(其中P = Django)。我将一起开发这两个版本，并尽可能确保差异保持在最顶端(配置)和最底端(数据模型)。GAE版本不一定是完美的，只要您知道如何使它完美，您就需要它。
It's not guaranteed that this is faster than writing and then porting, but my guess is it normally will be. The easiest way to spot any differences is to run the code, rather than relying on not missing anything in the GAE docs, so you'll likely save some mistakes that need to be unpicked. The Python SDK is a fairly good approximation to the real App Engine, so all or most of your tests can be run locally most of the time.
这并不能保证这比写作和移植要快，但我的猜测是，它通常是这样的。发现任何差异的最简单的方法是运行代码，而不是依赖于在GAE文档中没有遗漏任何东西，因此您可能会避免一些需要取消的错误。Python SDK是对真正的应用程序引擎的一种很好的近似，所以大多数情况下，您的所有或大部分测试都可以在本地运行。
Of course if you eventually decide not to port then you've done unnecessary work, so you have to think about the probability of that happening, and whether you'd consider the GAE development to be a waste of your time if it's not needed.
当然，如果您最终决定不移植，那么您已经做了不必要的工作，因此您必须考虑发生这种情况的可能性，以及如果不需要GAE开发，您是否会认为GAE开发是浪费时间。
#2
2
Basically, you will change the data model base class and some APIs if you use them (PIL, urllib2, etc).
基本上，如果您使用数据模型基类和一些api (PIL、urllib2等)，您将会更改它们。
If your goal is app-engine, I would use the app engine helper http://code.google.com/appengine/articles/appengine_helper_for_django.html. It can run it on your server with a file based DB and then push it to app-engine with no changes.
如果你的目标是app-engine，我将使用appengine助手http://code.google.com/appengine/articles/appengine_helper_for_django.html。它可以使用基于DB的文件在您的服务器上运行它，然后将它推到app-engine，不做任何更改。
#3
2
It sounds like you have awareness of the major limitation in building/migrating your app -- that AppEngine doesn't support Django's ORM.
听起来你似乎意识到了构建/迁移应用程序的主要限制——AppEngine不支持Django的ORM。
Keep in mind that this doesn't just affect the code you write yourself -- it also limits your ability to use a lot of existing Django code. That includes other applications (such as the built-in admin and auth apps) and ORM-based features such as generic views.
请记住，这不仅会影响您自己编写的代码，还会限制您使用大量现有Django代码的能力。这包括其他应用程序(如内置的admin和auth应用程序)和基于orm的特性(如通用视图)。
#4
1
There are a few things that you can't do on the App Engine that you can do on your own server like uploading of files. On the App Engine you kinda have to upload it and store the datastore which can cause a few problems.
在应用程序引擎上有一些事情你不能在你自己的服务器上做，比如上传文件。在应用程序引擎上，你需要上传和存储数据存储，这会导致一些问题。
Other than that it should be fine from the Presentation part. There are a number of other little things that are better on your own dedicated server but I think eventually a lot of those things will be in the App Engine
除此之外，演示部分应该没问题。有很多其他的小事情在你的专用服务器上比较好但是我想最终会有很多东西出现在App Engine中。
#1
8
Most (all?) of Django is available in GAE, so your main task is to avoid basing your designs around a reliance on anything from Django or the Python standard libraries which is not available on GAE.
Django的大部分(全部?)都在GAE中可用，因此您的主要任务是避免将设计建立在依赖于Django或在GAE上不可用的Python标准库的基础之上。
You've identified the glaring difference, which is the database, so I'll assume you're on top of that. Another difference is the tie-in to Google Accounts and hence that if you want, you can do a fair amount of access control through the app.yaml file rather than in code. You don't have to use any of that, though, so if you don't envisage switching to Google Accounts when you switch to GAE, no problem.
您已经确定了明显的差异，即数据库，因此我假设您已经掌握了这一点。另一个区别是绑定到谷歌帐户，因此，如果您愿意，可以通过app.yaml文件而不是代码进行大量的访问控制。不过，您不需要使用其中的任何一个，因此，如果您不打算在切换到GAE时切换到谷歌帐户，那么没有问题。
I think the differences in the standard libraries can mostly be deduced from the fact that GAE has no I/O and no C-accelerated libraries unless explicitly stated, and my experience so far is that things I've expected to be there, have been there. I don't know Django and haven't used it on GAE (apart from templates), so I can't comment on that.
我认为标准库中的差异主要可以从GAE没有I/O和没有c加速库(除非明确声明)这一事实中推断出来，我的经验是，到目前为止，我所期望的东西已经存在了。我不知道Django，也没有在GAE(除了模板之外)上使用它，所以我不能对此发表评论。
Personally I probably wouldn't target LAMP (where P = Django) with the intention of migrating to GAE later. I'd develop for both together, and try to ensure if possible that the differences are kept to the very top (configuration) and the very bottom (data model). The GAE version doesn't necessarily have to be perfect, as long as you know how to make it perfect should you need it.
我个人可能不会以稍后迁移到GAE为目标(其中P = Django)。我将一起开发这两个版本，并尽可能确保差异保持在最顶端(配置)和最底端(数据模型)。GAE版本不一定是完美的，只要您知道如何使它完美，您就需要它。
It's not guaranteed that this is faster than writing and then porting, but my guess is it normally will be. The easiest way to spot any differences is to run the code, rather than relying on not missing anything in the GAE docs, so you'll likely save some mistakes that need to be unpicked. The Python SDK is a fairly good approximation to the real App Engine, so all or most of your tests can be run locally most of the time.
这并不能保证这比写作和移植要快，但我的猜测是，它通常是这样的。发现任何差异的最简单的方法是运行代码，而不是依赖于在GAE文档中没有遗漏任何东西，因此您可能会避免一些需要取消的错误。Python SDK是对真正的应用程序引擎的一种很好的近似，所以大多数情况下，您的所有或大部分测试都可以在本地运行。
Of course if you eventually decide not to port then you've done unnecessary work, so you have to think about the probability of that happening, and whether you'd consider the GAE development to be a waste of your time if it's not needed.
当然，如果您最终决定不移植，那么您已经做了不必要的工作，因此您必须考虑发生这种情况的可能性，以及如果不需要GAE开发，您是否会认为GAE开发是浪费时间。
#2
2
Basically, you will change the data model base class and some APIs if you use them (PIL, urllib2, etc).
基本上，如果您使用数据模型基类和一些api (PIL、urllib2等)，您将会更改它们。
If your goal is app-engine, I would use the app engine helper http://code.google.com/appengine/articles/appengine_helper_for_django.html. It can run it on your server with a file based DB and then push it to app-engine with no changes.
如果你的目标是app-engine，我将使用appengine助手http://code.google.com/appengine/articles/appengine_helper_for_django.html。它可以使用基于DB的文件在您的服务器上运行它，然后将它推到app-engine，不做任何更改。
#3
2
It sounds like you have awareness of the major limitation in building/migrating your app -- that AppEngine doesn't support Django's ORM.
听起来你似乎意识到了构建/迁移应用程序的主要限制——AppEngine不支持Django的ORM。
Keep in mind that this doesn't just affect the code you write yourself -- it also limits your ability to use a lot of existing Django code. That includes other applications (such as the built-in admin and auth apps) and ORM-based features such as generic views.
请记住，这不仅会影响您自己编写的代码，还会限制您使用大量现有Django代码的能力。这包括其他应用程序(如内置的admin和auth应用程序)和基于orm的特性(如通用视图)。
#4
1
There are a few things that you can't do on the App Engine that you can do on your own server like uploading of files. On the App Engine you kinda have to upload it and store the datastore which can cause a few problems.
在应用程序引擎上有一些事情你不能在你自己的服务器上做，比如上传文件。在应用程序引擎上，你需要上传和存储数据存储，这会导致一些问题。
Other than that it should be fine from the Presentation part. There are a number of other little things that are better on your own dedicated server but I think eventually a lot of those things will be in the App Engine
除此之外，演示部分应该没问题。有很多其他的小事情在你的专用服务器上比较好但是我想最终会有很多东西出现在App Engine中。