Scala in Goozy

Alexey ZlobinE-Legion

Index

1. Goozy overview2. Scala's place3. Lift4. Cake pattern in scale5. Scalaz and other fancy stuff6. Summary

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

Top-level architecture

Scala's place

API server

Main functions:● Storage access● Background tasks (feed writing, e-mails)● Email sending● Text indexing

Why scala?

● Fast● Сoncise● Expressive● Advanced OO● Some functional stuff

○ Simple concurrency● All Java legacy

available

The team

● 2 persons● Strong Java background● Fancy about technologies● Love to try new things

Lift

Utilized features:● REST● JSON serialisation

That's it...

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 escaping

Poor code style● Extremely long map-match-if hierarchies● Mutable, difficult to debug LiftRules design

Lift: shift from

Some plans about migration to less sophisticated framework...

Ideally small and simple enough to be completely rewritten in case of any issue.

But we have a strong dependency from Boot and configuration

And there is some aspect-like hooks on HTTP processing, which are unportable.

Goozy API logical structure

Application is composed from three layers.

Each layer consists from several similar components. Like UserStorage, 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 is expressed in one less than 100 LOC file

+ Compile-time dependency checks

+ The biggest file is around 1000 LOC

- Long dependency lists● Poor design?

- Implicit dependency on mix-in order (linearisation strikes back)

● Prefer def and lazy

- A bit unclear how to deal with several dependencies of the same type but different runtime implementation

scalaz.ValidationOne 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 aggregation and reporting

+ The only imaginable way to deal with 20+ request parameters with 2-3 constraints on each

+ Unified approach to request validation and runtime error handling

+ Type-level check for correct error handling

- Monads and Applicatives cause massive brain damage

- Complicated error reports from the compiler

- You can't just ignore possibility of runtime exception

Validations and exceptionsProblem: exceptions are here

Solution: catch'em and convert!

Error handling: big picture

Lessons

1. 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

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

Testing

A lot of features

Very quickly evolved at the beginning

We 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 architecture

1. JUnit wrapper2. Scenario3. Library of available

operation on http interface4. Groovy's HTTPBuilder

Integration testing: problems

Groovy1. Dynamic typing2. Not obvious ways to do simple things3. One extra language in project

Execution time