A legfontosabb, hogy egyelőre csak Python nyelven lehet rá írni, a következő pedig valószínűleg a Java lesz, mert a Google általában ezekben fejleszt, van is rá valamilyen szabályzatuk: Python, Java, C++, JavaScript.

PHP belátható időn belül (mondjuk 1-2 év) valószínűleg nem lesz, ha egyáltalán. Ahhoz ugyanis nagyon másmilyen infrastruktúra kell, messze nem úgy van, hogy szimplán apt-get-elnek a Linuxra egy PHP-t, bár a Google (marketing) állítása szerint az egész nyelvfüggetlenül lett kialakítva... de ezt nem tudom elhinni. Persze jó lenne. (Asszem a Rails-re is hiába vártok.)

Az AppEngine egy SaaS környezet

Szóval az AppEngine egy szoftverszolgáltatás ahol a bent lévő eszközöket kell használnod és felejtsd el mondjuk a root jelszót, ez nem hosting, még csak nem is virtuális szerver, hanem ismételjük mégegyszer, szoftverszolgáltatás (Software as a Service). Cserébe robusztusságot és felfelé skálázódást kapsz, gyakorlatilag egy felhőbe fejlesztesz, miközben nem kell a felhőben futó példányokkal foglalkozni.

Kész framework-ök vannak, nem egy üres Python. Az AppEngine saját, rá jellemző környezettel bír, az oda írt dolgaid nem lesznek portábilisak (mondjuk hova is vinnéd). Van saját user authentication, templating, szerver-kérés kezelő és még jónéhány framework. A user authentication persze arra van kihegyezve, hogy használd a Google felhasználóbázisát, a Google account-okat, ki hitte volna.

Pénz

Az ingyenes részben 500 mega tárhely és 5 millió pageview van, ez magyarra fordítva: nem sok tárhely (arra használj valami mást), a pageview pedig itt nem "igazi" pageview, hanem minden egyes kérés a szerver felé egy pageview-nak számít, az AJAX-os kérések is természetesen.

Példa: ha a webes alkalmazásod átlagosan 10 kérésből rak össze egy oldalt és egy látogatás átlagosan 4 oldal megnézéséből áll, akkor egy egyedi látogatót 40 pageview-nak kell számolni, ami havi 125 000 látogatás, vagyis napi 4 167. (Átlag 2 kérésnél persze 20e fölé csúszol, ám az mégsem nagyságrendekkel több.) Tehát ha sikeres lesz a szolgáltatásod, akkor az AppEngine valamelyik fizetős csomagjába fogsz becsúszni, de ez nem csoda, játszani meg ingyen lehet rajta.

Datastore

A legnagyobb korlátozás nem a Python, hanem az AppEngine-ben lévő adatbázis-kezelő, a Datastore. Ez nem olyan, mint a MySQL vagy bármelyik általad ismert, főiskolán/egyetemen oktatott relációs adatbázis-kezelő, mert ő nem relációs adatbázis-kezelő.

Az adatokat nem rekordokban és azon belül mezőkben, hanem inkább objektumokban és azok tulajdonságaiban tárolja. Nemis táblákat kell definiálni, hanem objektum-modelleket. Ez abban jobb a hagyományoshoz képest, hogy bármelyik tárolt objektumhoz bármikor hozzápasszinthatsz egy új tulajdonságot (értéket), a relációs adatbázisban viszont ilyenkor egy új mezőt kell felvenni a táblában, ami macerásabb.

A gáz a lekérdezésekben van, messze nem olyan rugalmas, mint a relációs ügy. Ennyit tudsz mindössze: SELECT * FROM objektumtípus WHERE feltétel [AND feltétel...] ORDER BY valami ASC/DESC [valami ASC/DESC...] LIMIT offset, count OFFSET offset.

Nincs GROUP BY, nincs táblákat kapcsolunk össze (több FROM), nincs JOIN, nincs SUM, AVG, COUNT és egyebek! Nincs LIKE sem, csak teljes szavakra lehet keresni, szótöredékekre nem... Nyugodtan elfelejtheted az igazi SQL-t, a normalizálást és egyebeket, amiket a suliban tanítottak (illetve ne felejtsd el, de kezeld a helyén).

Arra ne nagyon számíts, hogy ezek a lehetőségek majd később úgy igazán bővülni fognak, mert a Datastore a BigTable-re épül: amit az nem tud mert más a filozófiája, a Datastore sem fogja tudni. Egyébként skálázódik szépen, de ő sem villámgyors, ezért van az AppEngine-ben Memcache API.

Eltörtem a mécsest?

Azért ne búslakodj, jónéhány dologra kiváló az AppEngine, de a blogodat vagy egy céges oldalt nem ide fogsz rakni.

8 hozzászólás

1. idézem 2008.06.19. 01:04
   • cadmagician
   akkor pl mire jó?
2. idézem 2008.06.19. 01:37
   • Hangya
   Alapos bemutató írás, jó ilyeneket olvasni!
   
   Annyit pontosítanék, hogy a template rendszere nem saját; a django-ét vette át egy az egyben.
   
   User kezelésre nem feltétlenül kell a google accountokat használni, ez csak egy lehetőség, de persze írhatsz sajátot.
   
   És ha már a GQL megkötéseinél tartunk, ami nekem nagyon hiányzik, hogy a WHERE feltételeknél csak egy oszlop szerint vizsgálódhatsz, tehát nincs olyan hogy where a>2 AND b
3. idézem 2008.06.19. 01:40
   • Hangya
   (hopsz, úgy látom a hozzászólás nem alakítja át a kacsacsőröket, a gt-t benn hagyja, lt-t kiszedi)
   
   szóval pl. WHERE a>2 AND b<3 nem működik
4. idézem 2008.06.19. 01:41
   • Hangya
   Szóval értitek :D
   
   Bocs a sok szemétért
5. idézem 2008.06.19. 04:02
   • Gábor
   @cadmagician Például apróbb webkettes izékre, mashupokra, ilyesmi.
   
   @hangya A doksi szerint lehet több tulajdonság szerinti is WHERE-elni.
6. idézem 2008.06.19. 04:38
   • Hangya
   Pontosítok: kisebb-nagyobb összehasonlításokat nem lehet egyszerre több oszlopon csinálni, a következőt dobja rá:
   
   BadFilterError: invalid filter: Only one property per query may have inequality filters (=, )..
7. idézem 2008.06.19. 04:40
   • Hangya
   (a zárójelben kisebbegyenlő, nagyobbegyenlő, kisebb és nagyobb operátorok álltak)
8. idézem 2008.06.19. 05:02
   • Gábor
   @hangya Szuper, mit ne mondjak...
   
   Egyébként < és > csak nyugodtan írd be, nem kell entitásként tolni a hozzászólásokban.

Legutolsó hozzászólások

DJ PLAYER Blue Edition: Gábor: Ja, és természetesen megy iPad-en is, hiszen _minden_ iOS app megy iPad-en.

DJ PLAYER Blue Edition: Gábor: Bug report-okat itt fogadunk: http://djplayer.net/page/bug_report_fixes

DJ PLAYER Blue Edition: hohand: Hello!A dj player mukodik iPad-on is?Tegnap feltettem, wifi-n athuztam ra zeneket,de amikor ranyomtam egy zeneszamra,error-t dobott es valami is!...

Uzsidoboz LED!: zo via Google Reader: vicces dolog, csak nem értem mire való

Uzsidoboz LED!: Gábor: @Benjamin Minek forogjanak? Egy falszínezőnek olyat nem kell tudnia, így is épp elég hatásosak.