wk voetbalpool webapp: dag 9

 
14 april 2010

Vandaag is het waarschijnlijk voornamelijk ‘recht zo die gaat’. Bij de stand-up meeting vertelt iedereen wat er gisteren gebeurd is, en het is vrij duidelijk waar we verder heen willen. De trac Wiki is in gebruik genomen en bevat nu het oorspronkelijke document van Simon waarin de gewenste functionaliteit beschreven staat, en er is nu een beschrijving van de REST API zoals we die nu hebben staan. Rikkert is inmiddels bezig met een Java util-klasse om met CouchDB te praten. Dat is handig, want omdat Scala op de JVM draait, kunnen we die direct vanuit Scala aanroepen. De communicatie tussen Java en CouchDB heeft hij inmiddels aan de praat, en hij probeert nu met XStream objecten naar JSON te serialiseren en die dan naar CouchDB te sturen en andersom.

Ondertussen zijn Jan-Willem en ik in het backend ook bezig met onze eigen JSON te bouwen en te parsen, en Anatoly is voor GWT nu ook druk bezig met zijn eigen JSON-(de)serializer. We moeten eens kijken of dit allemaal niet te vereenvoudigen is tot een enkele JSON-serializer. Het gebruik van GWT is hierbij een interessante factor, omdat die waarschijnlijk niet direct XStream kan gebruiken; we verwachten dat dat te ingewikkeld is voor GWT om naar JavaScript te compileren. Maar voorlopig gaat het met het handmatig parsen prima, en aan het eind van de dag heeft hij al best een aantal componenten zover dat ze echt met het domein praten.

Hoe we uiteindelijk de persistentie naar CouchDB gaan doen is nog even een open vraag. In Scala is het gemakkelijk om een trait te schrijven die je in alle domein-actoren mixt. Maar het lijkt mij zelf veel interessanter om te kijken of er niet ook iets van een persistency-Actor gebouwd kan worden die de persistentie voor de andere domein-actoren regelt.

Ondertussen ontstaat de vraag wat het verschil nou eigenlijk is tussen de GroupActor en de GroupViewActor. Beide houden leden en andere data bij, beide luisteren naar dezelfde events. Is het niet handig om deze twee te mergen? Maar dat is weer niet erg CQRS-compliant (als zoiets bestaat) omdat de (domein-)GroupActor dan tegelijkertijd de rol van reporting-component overneemt. Maar we komen erop uit dat de huidige GroupViewActor waarschijnlijk te uitgebreid is, omdat het nu een enkel componentje is die meerdere views laat zien: een ledenoverzicht, de top-10, de gemiddelde score van de groepsleden, … Daarentegen zou juist de GroupActor een ‘brede’ klasse moeten zijn die alle relevante data beheert voor de groep (zijn leden met hun scores en de gemiddelde score) terwijl daar meerdere ‘lichtgewicht’ componenten tegenover staan. Het front-end kan dan zelf van verschillende van deze views (die zelf alleen maar JSON-data teruggeven) een mooi overzicht samenstellen.

Nu we steeds meer actoren de lucht in trekken, lopen we tegen een ander probleem aan: coördinatie van de volgorde waarin dat gebeurt. Tussen het starten van een actor en het beginnen te luisteren zit kennelijk soms ook nog wat tijd, wat zorgt voor het volgende probleem: na het registreren van een nieuwe UserActor moeten ook een aantal ViewActors aangemaakt worden, bijvoorbeeld een die bijhoudt bij welke pools deze gebruiker is aangemeld. Dit gebeurt als reactie op het RegisterSuccess-event. Een daarvan is altijd de ‘Overall’-groep: daar hoort iedereen bij. Die groep luistert naar datzelfde event om de gebruiker toe te voegen. Maar nu kan het vanwege de gelijktijdige (concurrent) afhandeling gebeuren dat de Overall-groep al het event heeft uitgestuurd dat de gebruiker lid is geworden vóórdat de ViewActor in de lucht is die bijhoudt van welke pools de gebruiker lid is. Hier hebben we vervolgens een uitgebreide discussie over waarbij verschillende mogelijkheden voorbij komen om dit probleem op te lossen – bijvoorbeeld door onderscheid te gaan maken tussen een initialisatie- en een ‘aan-het-werk’-fase, of door gebruik van een soort proxy zolang nog niet alle views in de lucht zijn, of door gebruik te maken van futures, of …? Uiteindelijk kiezen we ervoor om in de UserFactory bij te houden welke views een ‘klaar-voor-gebruik’-event hebben verstuurd, en als we ze allemaal hebben, dan pas het definitieve RegisterSuccess-event te versturen. Mooi werk voor morgen…

En daarmee werd het half zes, en alles was wel.


Werken met ?
Kijk dan bij onze mogelijkheden voor zowel starters als ervaren engineers.


Categorieën: Development