Entries Tagged 'appengine' ↓

I wrote a new tutorial on building a search engine using Appengine, and Yahoo Search API here. This uses pure Appengine API, and not Django, and is a tutorial on how to use Appengine without Django.

I have posted two Tutorials for Using Django with Appengine.

• For people who do not know Django
• For people who already know Django see what we build in this tutorial

And here a few good links about the topic.

• James Bennet tells exactly why Appengine and Django are not so good together.
• Ian Bicking has an interesting take on how Appengine can change the economics of Python hosting.
• The guys at Joyent reading my mind on why I or you can not deploy any production site on Appengine. (Hint. you mean I can never move away, without writing half my code?)

We are hard at work building 42topics.com, and are looking at the best places to deploy this. So when I heard about Appengine, with out of box Django support(gasp!) I was delighted. After using it for a day, and posting a tutorial, I am so disappointed.

Peeves in no particular order.

• Appengine is a very constrained environment, so out goes any chance to run background jobs.
• The ORM-API is very similar to Django, but yet the Django API is much better. modelobj.filter('attr =', value1).filter('attr2 =', value2) or modelobj.filter(attr = value1, attr2 = value2). Putting entity level operations on modelobj.manager is much cleaner that making them classmethods, as argued here.
• Very half baked documentation. Releasing without sufficient testing on windows. If you follow the Getting started guide, and are on windows, I hope you like debugging regexes
• NO JOINS? Ok so I can use obj.master to simlute this. Umm can I get GROUP BY? What about UNION? Admittedly Bigtable is not relational, but are you telling me Google built all their search without a way to simulate GROUP BY.
• PDB does not work on dev server. With Django’s dev server, I put breakpoints with PDB all the time, and it works perfectly. With Appengine devserver, pdb will give you BDBQuit exceptions. I hope you enjoy debugging by reading logfiles.
• Modules used by django are empty.
• You can not start a dbshell on the dev server. (And django-admin framework does not work). When I am coding, I write the data insertion views first, and then the other views. Whether the Insert views are working or not can be checked immediately, from the db shell, or from admin. Here until I write the other views, I can not check on my create view.

The other flaws I can live with, but a dbshell not working and pdb breakpoints raising exceptions make this unusable for me. I guess I will stick with Django on a normal web host, and look at EC2, when we really need to scale.

Google launched their EC2 competitor, Appengine yesterday, and all hell broke loose. And in about 24 hours, the 10,000 accounts were used up. Currently it is tied to only working with python, and Django 0.96.1 works out of the box.

The Good

• Python powered. Django works out of the box.
• No sysadmining chores.
• Promise of infinite scalability with no configuration. (Ah!)
• Free for now.

The Bad

• Python powered, if you want to use ruby/java/php, sorry you are out of luck.
• Your code is tied to Google. You might be able to reuse most of your code, but the DB/ORM sepcific code, ah you are out of luck. And if you are building database backed websites, well most of your most complex code talk to ORM.
• Too magical. Explicit is better than implicit. On the dev server I do not know where my data is stored. If I change the data model, the changed models are available immediately. But well, how do you do it?
• Free for now, and no way to pay for when your usage out grows the free quota limits.