Tijdens de Logica Hackathon was het de bedoeling om de Google app engine te gebruiken als backend platform. In de uiteindelijke oplevering zat geen GAE meer vooral omdat het niet mogelijk leek om te verbinden met onze eigen XMPP-server. Verder was de netwerkverbinding nu niet echt stabiel om het maar zachtjes uit te drukken wat het samenwerken met een cloud provider weer moeilijk maakt. Weer thuis leek het een goed idee om GAE toch een keer uit te proberen. Ik wil mijn eerste ervaringen met jullie delen.
Na enig nadenken wat ik dan zou willen bouwen op het platform heb ik besloten om een simpele todo applicatie te bouwen en hiermee de mogelijkheden en beperkingen van GAE te onderzoeken. Het domein is voldoende simpel om niet te veel tijd hierin te steken. Oké, plan gemaakt laten we een account aanmaken op http://appengine.google.com/. Enkele formulieren en een verificatie sms verder kon ik eindelijk mijn applicatie aanmaken. Na het instaleren van de plug-in voor eclipse kon ik gaan ontwikkelen. Met behulp van de documentatie was het eerste (demo) project binnen no-time gedeployed.
Het viel mij direct op hoe eenvoudig ik een eerste deployment voor elkaar kreeg. Vaak als ik een ontwikkelomgeving met een bestaand project aan de gang wil krijgen op mijn laptop ben ik net zoveel tijd kwijt. En mijn verwachting was dat het waarschijnlijk wat meer tijd zou kosten om het een en ander in de cloud aan de gang te krijgen. Verder vind ik het pricing model dat GAE hanteert zeer interessant. Je kunt gratis beginnen met redelijk ruime quota’s en je gaat daarna pas betalen. Dus je kunt eerst proberen of een applicatie een succes is voordat je er zelf voor gaat betalen.
Nu weer terug naar de ontwikkeling. Als je een bestaande applicatie die nu draait op bijvoorbeeld een jboss server wilt omzetten richting GAE dan zijn er een aantal beperkingen. Onder andere:
- Een request moet binnen 30 seconden een response gegeven hebben. Een oplossing hiervoor kan zijn om een task-queue te gebruiken en je request op te splitsen in aparte worker threads die elk ook maar 30 seconden mogen draaien. Al met al een beperking.
- Bepaalde klassen uit de JRE mag je niet gebruiken. Denk aan javamail, en de IO klassen voor het schrijven naar file. Deze klassen zijn wel toegestaan. Het goede nieuws is dat Google wel alternatieven aanbiedt voor de verboden klassen.
De belangrijkste beperking is het migreren van JPA code. Aangezien Google geen relationele database heeft maar BigTable als persistentie laag wordt het moeilijk om dit deel van de applicatie om te zetten. Hoewel wordt geclaimd dat JPA code wordt ondersteund blijkt dit slechts een subset van de mogelijkheden. Hier is meer informatie te vinden over het opslaan van data. Ik gebruik nog steeds JPA in mijn code, maar dat is vooral omdat de syntax zo bekend is en ik daar niet meer over hoef na te denken.
Voor mijn applicatie wil ik een todo lijst hebben per gebruiker. Er is dus iets nodig als inloggen en het concept User. De GAE heeft een user API die dit allemaal voor je regelt. De authenticatie kun je op 3 manieren oplossen. Één voor gebruikers van Google apps voor your domain. En de andere twee zijn inloggen met je Google account en open id. Het enige dat je hoeft te doen is in je web.xml een security constraint te definiëren en de authenticatie manier te kiezen bij het aanmaken van je applicatie. Vervolgens kun je de users API gebruiken om de gebruikers informatie te gebruiken. Er is wel de beperking dat je maar 2 rollen hebt voor ingelogde gebruikers. De normale ingelogde gebruiker en de admin.
Unit-testen maken het makkelijker om de code later te refactoren. Dus ook voor deze simpele applicatie heb ik enkele unit-testen geschreven. Eigenlijk wil je niet dat je voor je elke test de server opnieuw moet starten. Dus je gaat je datastore mocken etc. Gelukkig heeft Google het ons gemakkelijk gemaakt door mocks voor de verschillende services te maken. Je kunt alle API’s mocken met behulp van deze testhelper. Helaas had ik zelf al mijn mocks gemaakt, dus note to self RTFM. Hieronder staat een stukje code hoe de testhelper gebruikt kan worden.
private final LocalServiceTestHelper helper = new LocalServiceTestHelper( new LocalUserServiceTestConfig(), new LocalDatastoreServiceTestConfig()) .setEnvIsAdmin(false).setEnvIsLoggedIn(true) .setEnvEmail(SOME_EMAIL) .setEnvAuthDomain(SOME_DOMAIN); @Before public void setUp() { helper.setUp(); } @After public void tearDown() { helper.tearDown(); } @Test public void someTest() { doTestSomethingWithDatastoreAndLoggedInUser(); } }
Natuurlijk zijn er nog andere dan technische bezwaren aan het hosten van een applicatie in een cloud. De data op die servers staat niet meer op eigen servers en dit kan juridische consequenties hebben. Gelukkig heb ik daar geen verstand van en ik wil me vooral richten op de technische aspecten. Mijn eerste ervaringen met Google app engine zijn voornamelijk positief. Ik heb het nog niet meegemaakt dat ik zo productief code kon schrijven. Dus als je met de beperkingen kunt leven, probeer het een keer, het is een makkelijke manier om een applicatie online te krijgen. Het is ook mogelijk om verschillende versies van de applicatie naast elkaar te draaien. Please do try this at home!
P.S. De mensen die graag mijn demo willen zien moet ik nog teleurstellen. Op dit moment is het slechts een hello world applicatie met een grote backend. Ik hoop binnen enkele weken een toonbare applicatie op te leveren en die zal ik zeker met jullie delen.
One response to “Please do try this at home: Google app engine”
[…] mijn vorige blog vertelde ik dat ik Google App Engine aan het testen was. Ook vertelde ik dat het op dat moment […]