How I 'hacked' the Google App Engine

A couple of days ago, I published my microdata generator tool* which still has to be integrated with schema.org.

The people at schema.org were very positive, and asked me if it would run on Google App Engine. I thought that would not be too problematic. Little did I know.

So, I jumped into the documentation and found the first surprise; Python2.7 instead of Python3.4. I had to downgrade my code. Not too traumatic. Change some libraries, change some lines of code. I had to redo the pickle file because that's incompatible.

I downloaded the SDK and set up everything. First error: no 'app'. Let's see...

app = webapp2.WSGIApplication([('/', MainPage),], debug=True)

Okay. I changed the MainPage into Controller.run_this, my tool's handler. Next error: run_this accepts three parameters, two given. Hmmm, I have to do something with the webapp2.RequestHandler. Not looking good.

Didn't I read somewhere that Google App Engine was using WSGI? My program is WSGI. It should just work, dammit, but how to pass my app to the App Engine?

Let's try...
app = Controller()

Next error: app doesn't have the __call__ method. Hmmm, no idea. Let's just debug the app engine with PyCharm... and there it was.

def __call__(self, environ, start_response):

Compared to my own run_this:
def run_this(self, environ, start_response):

Gotcha! I changed run_this into __call__ and Bob's your uncle. Works perfectly well on my machine. Runs perfectly well on the Google platform. Check it out: generator tool

How is that 'hacking'? Well, I had to dive into the innards of the Google App Engine to discover how to make my WSGI application work.

You can view the original Python3.4 code here.

*I've had to move away from the Google App Engine. My code is now hosted at https://www.pythonanywhere.com/

Comments

Popular posts from this blog

A recipe for failure

Ubuntu - Auto-mount an encrypted drive

Spaghetti code