2. Index
1. Goozy overview
2. Scala's place
3. Lift
4. Cake pattern in scale
5. Scalaz and other fancy stuff
6. Summary
3. What is Goozy?
A social network built around
the concept of sticky note
● A note could be left
anywhere in the Web.
● It is associated with
particular page element.
Central UI concept: user's
related feed with all new notes
and comments
9. Lift: issues
Localisation 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 escaping
Poor code style
● Extremely long map-match-if hierarchies
● Mutable, difficult to debug LiftRules design
10. Lift: shift from
Some plans about But we have a strong
migration to less dependency from Boot
sophisticated framework... and configuration
Ideally small and simple And there is some aspect-
enough to be completely like hooks on HTTP
rewritten in case of any processing, which are
issue. unportable.
11. Goozy API logical structure
Application is composed
from three layers.
Each layer consists from
several similar
components. Like
UserStorage,
GroupStorage, etc.
12. 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...
13. 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
14. Cake pattern: consequences
+ All top-level architecture - Long dependency lists
is expressed in one less ● Poor design?
than 100 LOC file
- Implicit dependency on mix-
+ Compile-time in order (linearisation strikes
dependency checks back)
● Prefer def and lazy
+ The biggest file is
around 1000 LOC - A bit unclear how to deal
with several dependencies of
the same type but different
runtime implementation
15. 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.
16. Validation: pros and cons
+ Comprehensible error - Monads and Applicatives
aggregation and reporting cause massive brain
damage
+ The only imaginable way
to deal with 20+ request - Complicated error reports
parameters with 2-3 from the compiler
constraints on each
- You can't just ignore
+ Unified approach to possibility of runtime
request validation and exception
runtime error handling
+ Type-level check for
correct error handling
19. Lessons
1. Always prefer simple tools
2. 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
20. References
1. http://www.assembla.
com/spaces/liftweb/wiki/REST_Web_Services - REST
support in Lift
2. http://jonasboner.com/2008/10/06/real-world-scala-
dependency-injection-di.html - complete cake pattern intro
3. https://gist.github.com/970717 - easy Validation example
21. Testing
A lot of features
Very quickly evolved at the beginning
We needed to exclude possibility of regression
22. 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
23. Testing: logical architecture
1. JUnit wrapper
2. Scenario
3. Library of available
operation on http interface
4. Groovy's HTTPBuilder
