4 ms·

I wrote about my (unsuccessful) app engine experience many years ago...hopefully they've improved since then. http://www-cs-students.stanford.edu/~silver/gae.h

I wrote about my (unsuccessful) app engine experience many years ago...hopefully they've improved since then. http://www-cs-students.stanford.edu/~silver/gae.html http://www-cs-students.stanford.edu/~silver/gae.html

boulos 11y ago
Good writeup! I think the main change is that App Engine has really morphed into a "You know, you don't have to use Datastore". Cloud SQL was added precisely because of the issues you raise: being on App Engine meant being in a totally foreign world, and not being able to get out easily. If you were to try again today, you'd take stock Django 1.9 via pip install Django -t lib and using vendoring: https://cloud.google.com/appengine/docs/python/tools/libraries27#vendoring https://cloud.google.com/appengine/docs/python/tools/librari... . You point it at your Cloud SQL instance in your DATABASES line (https://cloud.google.com/appengine/docs/python/cloud-sql/django#usage https://cloud.google.com/appengine/docs/python/cloud-sql/dja...) and you're done. tl;dr: Yep! Things have improved in the last 5 years. Disclosure: I work on Compute Engine.
- sspross 11y ago
  It sounds like you know what you're talking about. Would you mind to take a look at my issue/question on the appengine django skeleton[1]. The Problems start after you've pointed your database to cloud sql und start using GAE specific features like task queue etc. [1] https://github.com/GoogleCloudPlatform/appengine-django-skeleton/issues/14#issuecomment-196490921 https://github.com/GoogleCloudPlatform/appengine-django-skel...
  - boulos 11y ago
    For your first question (playing with Cloud SQL) you've got two options. Directly interact with Cloud SQL from your laptop or like you said have a "development MySQL" separate from prod / staging. Pointing at your Cloud SQL instance (maybe using a staging or development database) can be done in settings.py. The switch between modes let's you specify the IP address for your Cloud SQL instance when you're not on App Engine (which uses a special UNIX domain socket). We also recommend you connect over SSL when doing so outside (see more at the link I provided, or search for cloud sql ssl). Having a local environment for MySQL is also easy enough depending on your box, but has the usual difficulty of needing to have a good test suite / being populated with useful data. I think it's worthwhile if you can pull it off, but I've seen companies big and small decide its not worth it (and instead use a separate table or database on the same server, maybe as a different user as another line of "don't screw up prod"). Finally, the interaction between Django's development server and the App Engine one isn't great. My response was intended to remind people that if you're not looking to use App Engine specific APIs you really can just get going and almost not notice. But you should be able to run your migrations speaking to Cloud SQL remotely without needing to import say Task Queues. So my workflow was to use manage.py for things like that, while using the dev_appserver when I actually needed to emulate App Engine (as opposed to the Django runserver command). Does that help? Edit: I forgot to add that we're working on decoupling the "emulation" of our services so that this kind of interop works better. See https://cloud.google.com/sdk/gcloud/reference/beta/emulators/ https://cloud.google.com/sdk/gcloud/reference/beta/emulators... for Datastore and PubSub (and more on the way).

boulos 11y ago

Good writeup! I think the main change is that App Engine has really morphed into a "You know, you don't have to use Datastore". Cloud SQL was added precisely because of the issues you raise: being on App Engine meant being in a totally foreign world, and not being able to get out easily. If you were to try again today, you'd take stock Django 1.9 via pip install Django -t lib and using vendoring: https://cloud.google.com/appengine/docs/python/tools/libraries27#vendoring https://cloud.google.com/appengine/docs/python/tools/librari... . You point it at your Cloud SQL instance in your DATABASES line (https://cloud.google.com/appengine/docs/python/cloud-sql/django#usage https://cloud.google.com/appengine/docs/python/cloud-sql/dja...) and you're done. tl;dr: Yep! Things have improved in the last 5 years. Disclosure: I work on Compute Engine.

sspross 11y ago
It sounds like you know what you're talking about. Would you mind to take a look at my issue/question on the appengine django skeleton[1]. The Problems start after you've pointed your database to cloud sql und start using GAE specific features like task queue etc. [1] https://github.com/GoogleCloudPlatform/appengine-django-skeleton/issues/14#issuecomment-196490921 https://github.com/GoogleCloudPlatform/appengine-django-skel...
- boulos 11y ago
  For your first question (playing with Cloud SQL) you've got two options. Directly interact with Cloud SQL from your laptop or like you said have a "development MySQL" separate from prod / staging. Pointing at your Cloud SQL instance (maybe using a staging or development database) can be done in settings.py. The switch between modes let's you specify the IP address for your Cloud SQL instance when you're not on App Engine (which uses a special UNIX domain socket). We also recommend you connect over SSL when doing so outside (see more at the link I provided, or search for cloud sql ssl). Having a local environment for MySQL is also easy enough depending on your box, but has the usual difficulty of needing to have a good test suite / being populated with useful data. I think it's worthwhile if you can pull it off, but I've seen companies big and small decide its not worth it (and instead use a separate table or database on the same server, maybe as a different user as another line of "don't screw up prod"). Finally, the interaction between Django's development server and the App Engine one isn't great. My response was intended to remind people that if you're not looking to use App Engine specific APIs you really can just get going and almost not notice. But you should be able to run your migrations speaking to Cloud SQL remotely without needing to import say Task Queues. So my workflow was to use manage.py for things like that, while using the dev_appserver when I actually needed to emulate App Engine (as opposed to the Django runserver command). Does that help? Edit: I forgot to add that we're working on decoupling the "emulation" of our services so that this kind of interop works better. See https://cloud.google.com/sdk/gcloud/reference/beta/emulators/ https://cloud.google.com/sdk/gcloud/reference/beta/emulators... for Datastore and PubSub (and more on the way).