Google App Engine rapid deployment
Our context is about deploying small to medium applications fast. By fast I mean w/o having to do any server customization or worrying about resources. In GAE you pay the amount of resources that you use, be it CPU time, storage or email storage. The free quota is more than enough to get someone started and see a live app.
To eat our own dog food, me and Calvin started this adventure, with the goal that after one week we have a marketable product. Even though the barebone functionality of the app could be developed faster, we planned one week because we wanted to give the user’s experience a much greater attention, as any app should.
As development methodology we practiced the usual, Pair Programming, just that this time it sounded more like Pair Product-building, because we focused on both the interface, backend and business logic.
This time we chose to use Kay Framework. Kay is a light-weight framework, which bundles Werkzeug for the core work ( debugger, request and response objects, HTTP utilities, cache control headers, HTTP dates, cookie handling, file uploads, a powerful URL routing system ) and Jinja2 for the templating engine. Kay also follows the MVC dogma and allows Test Driven Development, which saves a lot of headaches. Being small, you can work with Kay without having to check the docs, since there aren’t many chapters to remember.
Tip: Werzkeug has an interactive debugger, in the browser’s traceback whenever there’s an error, you can start an interactive shell with all the local variables.
Bootsraping :
- Git
- GAE account
- Adding in Kay Framework
- Starting our first app that served a static page
This was a walk in the park.
Setting up our first model was easy too, since the GAE docs explain most of the fields very well. The only slight issues were:
- adding choices in string fields, to generate drop-down select boxes. We decided a set of values with one dimension was enough for our needs.
- deciding which base User model to extend. Kay Framework provides some options for user/password combinations or Google Accounts and we decided to go with a custom extension of a Google Account, so we can extend it the future with other Google applications.
Tests passed, moving on.
Having some basic logic, we needed some front-end. Then we hit a big bump: URL mapping. Being spoiled by Django’s regex URLs, Werkzeug URL routing looked like a monster. Mounting points, endpoints, no regex for the GET variables. Defining a new URL implies some code duplication, because Werkzeug defines an alias from the standard URL which is /app_name/view_name. Kay allows you to define whatever name you want for the view function, so it makes an alias from the endpoint name to the view which you defined.
Example:
- # Werkzeug is expecting the URL /job/country to
- # be mapped to the country() view function
- def make_rules():
- return [
- EndpointPrefix('job/', [
- Rule('/country//', endpoint='country'),
- ]),
- ]
- # Make an alias for /job/country/ to be
- # mapped to by_coutry() view
- all_views = {
- 'job/country': job.views.by_country,
- }
One main advantage is that you can have multiple custom URLs mapped to the same view.
Tip: Errors in views ( missing imports, wrong imports, syntax errors ) raise a 404 for an URL. It’s a bit misleading.
Next we experimented how GAE handles email sending. The process turned out to be straightforward. It can send plain-text or HTML emails, and the first 2000 are free.
Tip: Emails can only be sent from the Administrator’s address, so all emails come from one of your application administrators. We bypassed this by setting a no-reply address as an admin in the GAE panel.
We added in PayPal integration too. Tip: read PayPal docs very very well, since you might need to do IPN handling from scratch.
On the template language front, Jinja2 is powerful, maybe too powerful. An average designer should know HTML and CSS, on which knowledge of a templating language can be added.
The problem is Jinja2 has a steeper learning curve than Django’s templating language. For example: in Jinja2, you need to know if you’re calling an attribute or a method. The built-in filters are not that helpful and they still have a coding flavour to them, which might scare a designer.
On the good side, Jinja2, as DTL, has good translation support.
Tip: Jinja2 doesn’t have DTL’s template tags. We put that logic in the views and used {% include %}
Form handling doesn’t give many alternatives in Kay Framework. Either you display the form with <dd> and <dt> which is the default format, or you display it field by field. No .as_ul() , .as_table() or as_p() here. I guess not that many Kay Framework users needed that.
Friday came, product was done and it went live. More info about that product will come at another time and in another place.
The blade of Django knowledge was two sided. Personally, now I like Django even more. GAE’s limitations seem awkward to someone coming from custom setups with MySQL or PostgreSQL, but they can be bypassed with some creative thinking and they send you back to rethink you idea, cutting off all the excessive features, which might be an over-kill anyway. Plus it’s free. If the free quota is not enough for your big plans, you pay as you go, based on usage.
Disclaimer: Kay Framework is open source, so all my complaints about it can be fixed and improved by contributing. We will do so, if we will see this as appropriate.
Leave a Comment :