Efter att ha introducerat Google App Engine och beskrivit hur man kan använda den plattformen för att bygga sitt eget CDN så är det nu dags att gå igenom lite mer detaljer om hur man använder Google App Engine för att utveckla sina egna webbapplikationer. Det är relativt enkelt att använda Google App Engine eftersom det finns ett kraftfullt ramverk som man kan använda, en distribuerad databas, många användbara APIer, en lokal utvecklingsmiljö och en dashboard för att hantera applikationer som är i produktion.

För att utveckla till Google App Engine så krävs att du har Python installerat och att du har installerat Google App Engines SDK. För att ladda upp och köra en applikation så måste du också ha ett Google App Engine konto och registrera din applikation där. Om du inte redan har allt detta så följ stegen i del 2 i denna artikelserie om Google App Engine så har du allt uppsatt på några minuter.

Använd ett ramverk

Django är ett Model-View-Controller Pythonramverk för webbutveckling. Django underlättar väldigt om man vill utveckla en webbapplikation med en databas i botten, vilket i princip täcker alla webbapplikationer. I stora delar är Django väldigt likt Ruby on Rails (även om Django var först). Eftersom alla Google App Engine applikationer måste vara skrivna i Python så kan man spara mycket utvecklingstid genom att använda Django. Google App Engine kommer med sitt eget enkla ramverk som kallas webapp framework, men det är rekommenderat att använda Django då man får väldigt mycket gratis.

Det enklaste sättet att använda Django för Google App Engine är att använda Google App Engine helper for Django. Ladda ner denna helper och använd den som grund för alla Google App Engine projekt. Om du kör på Windows så krävs att du kopierar “.google_appengine” katalogen från din Google App Engine katalog till din projektkatalog för att allt ska fungera korrekt. Mer detaljer om hur man installerar och använder Django tillsammans med Google App Engine hittar du i denna artikel.

Mer information om Django finns på djangobook.com, men det är det viktigt att veta att Django på Google App Engine inte fungerar exakt som Djano gör i vanliga fall. En del funktionalitet, som tex Djangos admin interface finns inte i Google App Engine versionen. Det finns även skillnader i hur modeller och vissa utilities fungerar (och faktiskt vilka utilities som ingår), vilket beror på begränsningarna i Google App Engines plattform. De flesta av dessa skillnader hanteras av ovan nämnda Google App Engine helper for Django på ett bra sätt.

Konfigurera

Den viktigaste konfigurationsfilen för Google App Engine är app.yaml. Där specificerar man den “application identifier” som man har registrerat på sitt Google App Engine konto på appengine.google.com, detta är alltså det unika namnet på applikationen. Denna fil används bla när man laddar upp sin applikation till produktionsmiljön för att tala om för Google App Engine vad det är som laddas upp.

Här är ett exempel på en app.yaml fil:

<br /> application: helloworld<br /> version: 1<br /> runtime: python<br /> api_version: 1

handlers:

– url: /static

static_dir: static

– url: /.*

script: main.py

Om du använder Django för din applikation så har du ett par konfigurationsfiler till att tänka på. I urls.py konfigureras hur olika URLer ska hanteras och i settings.py specificeras vilka Django applikationer som ingår i ett projekt. Läs mer om dessa Djangofiler på djangobook.com.

Använd den distribuerade databasen

Datastore är Google App Engines motsvarighet till en databas. Eftersom data lagras utspritt över en massa olika servrar distribuerade över hela världen så fungerar inte Datastore som en SQL databas, men med hjälp av Google App Engines Datastore API så är det inga störrer problem att använda Datastore. Motsvarigheten till tabeller heter Modeller och motsvarigheten till rader i en tabell heter Entities. Med Datastore kan man göra (nästan) alla saker som man kan göra med en vanlig SQL databas. Det finns transaktioner, relationer mellan entities, nycklar etc. Det finns även ett enkelt query language, motsvarigheten till SQL som heter GQL. Mer information om Datastore finns i Google App Engine dokumentationen.

Med Google App Engines APIer får man mycket gratis

Förutom ovan nämnda Datastore APIet så har Google App Engine flera andra APIer som underlättar när man skriver applikationer. Det finns APIer för bildhantering, för att hantera email och caching, men de två mest användbara APIerna är Users APIet och URL Fetch APIet.

Med Users APIet så kan man använda Google autentisering av användare, dvs användare kan logga in i din applikation med sin GMail address. Detta är en stor fördel eftersom du som applikationsutvecklare får hela infrastrukturern med sessionshantering, in/utlogging, registrering etc på köpet.

URL Fetch API är till för att hämta in data från externa källor, tex genom att kalla på ett API eller för att läsa in ett RSS feed. Det är inte tillåtet att kalla på externa källor på något annat sätt än via URL Fetch API (vilket gör att vissa tredjeparts Python bibliotek inte fungerar på Google App Engine).

Utveckla lokalt

I Google App Engines SDK ingår en lokal webserver som simulerar produktionsmiljön. Starta denna lokala server med kommandot:

python dev_appserver.py <GAE projekt>

Där “GAE projekt” är sökvägen till den katalog där du har ditt Google App Engine projekt, tex den katalog där du har Google App Engine helper for Django installerat. dev_appserver.py skriptet hittar du i din Google App Engine katalog. När den lokala servern är startad så kan du komma åt din applikation på http://localhost:8080. Den lokala webservern simulerar som sagt Google App Engines produktionsmiljö, så man kan testa att logga in och logga ut, spara data i Data Store etc. Det finns även en lokal Development Console där man kan se vad ens lokala Datastore innehåller, den kommer man åt via http://localhost:8080/_ah/admin.

Tips: Använd flaggan --debug när du startar den lokala servern för att få veta mycket mer information om vad som händer.

Produktionssätt din applikation

När väl en applikation är klar att produktionssättas så görs det via ett enkelt kommando:

python appcfg.py update <GAE projekt>

appcfg.py finns i Google App Engine katalogen och “GAE projekt” är den lokala sökvägen till ditt Google App Engine projekt. Detta skript använder inställningarna från konfigurationsfilen app.yaml för att ta reda på vilken application identifer att använda, så det är viktigt att detta är korrekt innan du produktionssätter. Skriptet kommer att fråga efter ditt användarnamn och lösenord till det Google konto du använde för att skapa din Google App Engine applikation. Så fort din applikation är produktionssatt så kan du använda den via URLen http://<application identifier>.appspot.com/.

Administrera applikationen

En Google App Engine applikation kan administreras via Google App Engine dashboard. Denna nås via http://appengine.google.com/dashboard?app_id=<application identifier>. På din dashboard kan du kontrollera hur mycket resurser som har använts de senaste 24 timmarna, kontrollera dina loggar och använda den sk Data Viewer för att se vilken data som finns i din Datastore.

Det går också att konfigurera din applikation. Man kan där ge andra utvecklare tillgång till applikationen så att man kan vara ett helt team som utvecklar och administrerar den. Det går också att koppla domäner till din applikation (det hittar man i den konstigt namngivna “Versions” sektionen), http://<application identifier>.appspot.com/ är ju inte världens sexigaste URL. För att använda en domän till din Google App Engine applikation så måste domänen använda Google Apps. Det går också bra att använda subdomäner för att köra Google App Engine applikationer, personligen så kör jag tex en Google App Engine applikation på chat.blendapps.com medans blendapps.com kör WordPress.

Mer om Google App Engine

Detta är del 3 av 4 i en artikelserie om Google App Engine. Det är en mycket bra plattform, men den passar inte för alla projekt. Den sista delen kommer att ta upp många av de begränsningar som finns när man använder Google App Engine samt hur man kan ta sig runt en hel del av dem.