waprin

The built-in Django libraries for Django on App Engine are severely outdated. I have new guides that just vendor in recent version:

https://cloud.google.com/python/django/appengine

However there are a lot of tricky issues with Django on App Engine so I would also look into Djangae:

https://github.com/potatolondon/djangae

As far as Kubernetes, the OP and I had some independent discovery and started working on similar material at the same time. I also have some Django/Kubernetes content, both CloudSQL (MySQL) and Postgres in Kubernetes:

https://cloud.google.com/python/django/container-engine (CloudSQL)

https://medium.com/google-cloud/deploying-django-postgres-re... (Postgres)

My biggest reason for running the database in Kubernetes is a) CloudSQL doesn't currently support Postgres and b) it's interesting. Seems like OP had similar motivations.

Obvious disclosure: I work for GCP.

It's obviously to a large degree personal preference, opinionated frameworks vs microframeworks. The reason why I would still use Django even if I wasn't using the ORM is because

1) I'm still probably using the ORM. I was just noting that for any data that the ORM doesn't fit well, you don't have to use it.

2) Why is Flask "lighter weight" than Django? From my perspective, as soon as you start writing a real app, you end up reinventing all these basic things like file layout using your own conventions, instead of a standard one that people are familiar with. The mental burden of figuring out your special snowflake conventions makes it 'heavier' weight to me. But again, personal preference :) Flask is obviously much better for really simple stuff, and does provide a great framework for extensions, even if I still lean towards Django.

I like Flask a lot, but I take issue with:

> It doesn't force a data model / DB onto me - I can just plug in whatever I have (unlike Django).

Django doesn't force a data model onto you anymore than Flask does - nobody is forcing you to use the Django ORM. Any database code you write for a Flask app could be re-used in a Django app.

What the Django ORM does do is allow you to write portable apps and extensions. For example, suppose someone writes an extension for Flask that uses SQLAlchemy. If I'm writing a Flask app and only have a Mongo database available, I can't use that extension. On the other hand, if someone uses the Django ORM to write that extension, as long as I have a Django backend for my database, I can use their extension. It abstracts away the underlying datastore. Besides just which database you are using, you can also write a variety of code that works with Django models. Now granted, this abstraction can be severely leaky and flawed at times, but it's still quite powerful overall. Django provides a conventional, standard way to address the issue of interacting with data in a general way. Again, nobody is forcing you to use it, because you can just bypass the ORM and write your database code directly. It's just a powerful paradigm if you do embrace it.

I agree the docs could use some improvements.

After playing around with it, I'm not sure if the filesystem works, which makes sense given you just have a bucket or repo underneath and the code can be called at unpredictable times. You can, however, add additional javascript files via the package.json and import them, so if you can express your data as JSON or base64, you're good to go. Maybe there is a way to add other types of resources via the package.json but I haven't figured it out yet.

Generally you would interact with Cloud SQL using a regular node MySQL library, since it's just managed MySQL. The API would only be used to automate creating and setting up the CloudSQL instance.

I haven't actually tried it out yet (about to) , but just by reading the instructions on deploying, it looks like you stage your code in a GCS bucket or on a Git repository (Google Cloud Source), so I think your local data would refer to any files in that bucket/repository along with your code.

*edit note: looks like you can definitely add more files via the package.json and import them as node modules, but I wouldn't rely on reading and writing from the file system.

As for persistency, if it's just Javascript code you can install node modules to accomplish what you want including talking to those cloud APIs. Unfortunately Bigtable might be the exception since I'm not sure if there's a good nodejs client yet (Bigtable only supports gRPC, not REST), but you could use Cloud Datastore instead.

Firebase will also be a very popular choice for persistence. Cloud Functions naturally complements Firebase to complete Backend-as-a-Service. The hope of Firebase is you don't need a server at all, but sometimes you have logic that really doesn't belong on a client (background jobs, "master" logic). Cloud Functions can fill in those gaps.

Firebase: https://www.firebase.com/

hand-rolled clients nodejs clients for google cloud apis: https://github.com/GoogleCloudPlatform/gcloud-node

auto-generated nodejs clients for google apis: https://github.com/google/google-api-nodejs-client

disclosure: work for GCP

I just created a PR to deploy Kinto on Google App Engine (Managed VMs).

https://github.com/GoogleCloudPlatform/python-docs-samples/p...

If there's interest I'll try to flesh it out more.

Sorry, I was asking if you accept article contributions.

This site is absolutely excellent. There are a lot of things in math that I sort of had a handle of the mechanics of, but less so the intuitions for, which this site fills in well:

I really liked the explanation of sine as something that makes things 'circly'.

http://betterexplained.com/articles/intuitive-understanding-...

Does the site take external contributions?

I think you were ahead of the curve. I have seen multiple companies that seem to think of front-end as "lesser" engineering, but then struggled to fill front-end roles more than any other position, and struggle to build great UIs. "Front-end" still has a stigma of taking a PSD and turning it into HTML/CSS, even though these days front-ends are getting extremely sophisticated and require tons of strong coding skills. Ultimately supply/demand work in your favor. And I wouldn't take anything a PHP expert has to say about "serious" developer roles too seriously.

Not necessarily. In fact it can get in the way because complexity theory ignores all those ugly little constant numbers. More important than complexity theory is actually doing your own measuring and benchmarking, something I've seen forgotten during engineering attempts far more often.

I think DevOps is a bit of a fad anyway, because a huge chunk of the problems people are solving will soon be solved by off-the-shelf standard cloud solutions. It makes no sense for everyone to be writing their own deployment/configuration Chef and Docker setups when they can just use increasingly powerful and flexible PaaS options like AppEngine/Heroku.