Index1. Goozy overview2. Scalas place3. Lift4. Cake pattern in scale5. Scalaz and other fancy stuff6. Summary
What is Goozy?A social network built aroundthe concept of sticky note ● A note could be left anywhere in the Web. ● It is associated with particular page element.Central UI concept: usersrelated feed with all new notesand comments
Lift: issuesLocalisation performance ● Hand-made localisation on standard resource bundles gave 4 times throughput improvement.Very memory-consuming JSON serialisation. ● Not so efficient PrettyPrinter is used ● Functional-styled string escapingPoor code style ● Extremely long map-match-if hierarchies ● Mutable, difficult to debug LiftRules design
Lift: shift fromSome plans about But we have a strongmigration to less dependency from Bootsophisticated framework... and configurationIdeally small and simple And there is some aspect-enough to be completely like hooks on HTTPrewritten in case of any processing, which areissue. unportable.
Goozy API logical structureApplication is composedfrom three layers.Each layer consists fromseveral similarcomponents. LikeUserStorage,GroupStorage, etc.
Conceptual problems● Components of each level depend from each other● Components most likely have several dependencies from the previous level● A lot of common stuff inside a level ○ Every storage needs a DB connection ○ Every service needs an entire storage system and access to text indexes ○ Etc...
The solution: cake pattern● Each logically closed piece of functionality is represented as component● Dependencies are expressed as self-type● Common features expressed as mix-ins● Common combinations of functionality are expressed as mix-ins of several components
Cake pattern: consequences+ All top-level architecture - Long dependency listsis expressed in one less ● Poor design?than 100 LOC file - Implicit dependency on mix-+ Compile-time in order (linearisation strikesdependency checks back) ● Prefer def and lazy+ The biggest file isaround 1000 LOC - A bit unclear how to deal with several dependencies of the same type but different runtime implementation
scalaz.Validation One sweet morning I sent a link to the colleague... On the next morning we had a new dependency and totally refactored request parameters analysis. Now everything is validated.
Validation: pros and cons+ Comprehensible error - Monads and Applicativesaggregation and reporting cause massive brain damage+ The only imaginable wayto deal with 20+ request - Complicated error reportsparameters with 2-3 from the compilerconstraints on each - You cant just ignore+ Unified approach to possibility of runtimerequest validation and exceptionruntime error handling+ Type-level check forcorrect error handling
Validations and exceptionsProblem: exceptions are hereSolution: catchem and convert!
Lessons1. Always prefer simple tools2. Options and Eithers (Validations): they really work ○ It is possible to live with both exceptions and eithers ○ Performance consequences are not clear ○ Some times I had to use things far behind my understanding (sequence, traverse)3. Server-side testing is difficult ○ Testing approach should be established before any code is written
References1. http://www.assembla. com/spaces/liftweb/wiki/REST_Web_Services - REST support in Lift2. http://jonasboner.com/2008/10/06/real-world-scala- dependency-injection-di.html - complete cake pattern intro3. https://gist.github.com/970717 - easy Validation example
TestingA lot of featuresVery quickly evolved at the beginningWe needed to exclude possibility of regression
Testing: solution● Integration testing from the client point of view● All test deal only with the http interface● Every case is a short (5-10 reqs.) scenario● Every case is wrapped into JUnit test for convenience
Testing: logical architecture1. JUnit wrapper2. Scenario3. Library of available operation on http interface4. Groovys HTTPBuilder
Integration testing: problemsGroovy 1. Dynamic typing 2. Not obvious ways to do simple things 3. One extra language in projectExecution time
A particular slide catching your eye?
Clipping is a handy way to collect important slides you want to go back to later.