Slide 1

Slide 1 text

Scala@TomTom TELLUS Team

Slide 2

Slide 2 text

© 2013 TomTom. All rights reserved. • Topics • Project Description (?) • Non-functional requirements • Technology stack • General overview of the system architecture • REST API • How to define • How to test • Flow as an Actor • How to define • Future Composition • How to test • Store Actors • Brief overview • Bonus • Loan Pattern 2

Slide 3

Slide 3 text

© 2013 TomTom. All rights reserved. NavCloud • NavCloud is a server-based application, implements a data service to store, maintain and share personal navigation application data in the cloud. 3

Slide 4

Slide 4 text

© 2013 TomTom. All rights reserved. Non-Functional Requirements • Performance (short response time, least resource locking and blocking) • Horizontal scalability + Fault tolerance • Testability (functionality and performance) • Easy to build and deploy • Security • Platform availability (through SDKs) • Maintainable codebase 4

Slide 5

Slide 5 text

© 2013 TomTom. All rights reserved. SBT 5

Slide 6

Slide 6 text

© 2013 TomTom. All rights reserved. Client Applicati on Flow Overview Server Flow Actor Flow Actors PUT GET GetEntity Flow Actor SetEntity REST API Actor Riak Store Actor Riak Store Actor Store Actors GetEntityById UpdateEntity Riak Riak Client Streaming 6

Slide 7

Slide 7 text

© 2013 TomTom. All rights reserved. Client Applicati on REST API Server Flow Actor Flow Actors PUT GET GetEntity Flow Actor SetEntity REST API Actor Riak Store Actor Riak Store Actor Store Actors GetEntityById UpdateEntity Riak Riak Client Streaming 7

Slide 8

Slide 8 text

© 2013 TomTom. All rights reserved. Spray • An open-source toolkit for REST/HTTP and low-level network IO on top of Scala and Akka. 8

Slide 9

Slide 9 text

© 2013 TomTom. All rights reserved. Spray-Routing • Provides a high-level routing DSL to define RESTful web services. 9

Slide 10

Slide 10 text

© 2013 TomTom. All rights reserved. REST API Definition using Spray-Routing 10

Slide 11

Slide 11 text

© 2013 TomTom. All rights reserved. Route & Directives • Route: RequestContext => Unit • Directives: Building block to construct complex route structures. • It does transforming, filtering, extracting from, and completing the request context and passing the result to inner directives. 11

Slide 12

Slide 12 text

© 2013 TomTom. All rights reserved. More Details 12

Slide 13

Slide 13 text

© 2013 TomTom. All rights reserved. Entity Definition • Simple case classes • JSON format is specified in companion objects. • Spray-JSON takes care of unmarshalling (out of scope of this presentation) 13

Slide 14

Slide 14 text

© 2013 TomTom. All rights reserved. Authenticate Directive 14

Slide 15

Slide 15 text

© 2013 TomTom. All rights reserved. Authenticate Directive 15

Slide 16

Slide 16 text

© 2013 TomTom. All rights reserved. Authenticator 16

Slide 17

Slide 17 text

© 2013 TomTom. All rights reserved. REST API Implementation 17

Slide 18

Slide 18 text

© 2013 TomTom. All rights reserved. How to Unit Test? 18

Slide 19

Slide 19 text

© 2013 TomTom. All rights reserved. Spray-testkit • provides a dedicated test DSL that makes actor-less testing of route logic easy and convenient. • Supports scalatest and specs2 19

Slide 20

Slide 20 text

© 2013 TomTom. All rights reserved. 20

Slide 21

Slide 21 text

© 2013 TomTom. All rights reserved. Client Applicati on Flow as an Actor Server Flow Actor Flow Actors PUT GET GetEntity Flow Actor SetEntity REST API Actor Riak Store Actor Riak Store Actor Store Actors GetEntityById UpdateEntity Riak Riak Client Streaming 21

Slide 22

Slide 22 text

© 2013 TomTom. All rights reserved. Flow as an Actor 22

Slide 23

Slide 23 text

© 2013 TomTom. All rights reserved. Flow as an Actor • Message case classes: Actors communication media (Nothing new) 23

Slide 24

Slide 24 text

© 2013 TomTom. All rights reserved. 24

Slide 25

Slide 25 text

© 2013 TomTom. All rights reserved. Flow Flow as an Actor • Actors are responsible to handle the business logic of the system • Per request a new flow actor is created (thanks to actor because they are lightweight) • Flow actors are children of ApiActor (implementation of RestApi) • Currently, supervision strategy is default which means upon exception the actor is restarted (is it right???!) 25

Slide 26

Slide 26 text

© 2013 TomTom. All rights reserved. Base Flow Actor • Consists of some helper functions in order to complete the request • All of flow actors extends this actor 26

Slide 27

Slide 27 text

© 2013 TomTom. All rights reserved. Future Composition • A Future is an object holding a value which may become available at some point. • Future Composition: Chaining multiple futures without without being blocked. 27

Slide 28

Slide 28 text

© 2013 TomTom. All rights reserved. Future Composition 28

Slide 29

Slide 29 text

© 2013 TomTom. All rights reserved. How to Unit Test? 29

Slide 30

Slide 30 text

© 2013 TomTom. All rights reserved. Do You Remember Base Flow Actor?? • In unit tests, we override these functions to instead of completing http request, send us back a message to be captured 30

Slide 31

Slide 31 text

© 2013 TomTom. All rights reserved. Actor Testing Techniques 31

Slide 32

Slide 32 text

© 2013 TomTom. All rights reserved. And the Test... 32

Slide 33

Slide 33 text

© 2013 TomTom. All rights reserved. Client Applicati on Server Flow Actor Flow Actors PUT GET GetEntity Flow Actor SetEntity REST API Actor Riak Store Actor Riak Store Actor Store Actors GetEntityById UpdateEntity Riak Riak Client Store Actors Streaming 33

Slide 34

Slide 34 text

© 2013 TomTom. All rights reserved. Store Actors • Store actors are the children of flow actors. So, per request we will have a flow actor together with a store actor as its child. • Driver friendly data types are the communication media at this level. • We use Riak Client Library to communicate to riak using its HTTP interface. Since it uses actors to provide non-blocking client, its model is consistent with our model. (future composition etc.) • Everything in Riak is key-value. We use JSON format for our values => Same marshalling and unmarshalling mechanism exists at RestApi level needed here which is encapsulated by Riak client. • Decreasing impedance mismatch??! • Bucket settings are done in store actors. 34

Slide 35

Slide 35 text

© 2013 TomTom. All rights reserved. Store Actors 35

Slide 36

Slide 36 text

© 2013 TomTom. All rights reserved. Wanna Have Some Fun? • Loan Pattern: it would loan a resource to your function • Usage: Hiding Java boiler-plate code while working with resources • Ingredient: Typed higher order curried function. 36

Slide 37

Slide 37 text

© 2013 TomTom. All rights reserved. Loan Pattern 37

Slide 38

Slide 38 text

© 2013 TomTom. All rights reserved. How to Use? 38

Slide 39

Slide 39 text

© 2013 TomTom. All rights reserved. Conclusion • Almost everything can be modeled as actors in an actor system. With this facts, non-blocking calls are there! • Complexities of asynchronous programming are hidden using future composition. • Using internal DSLs increases the readability and maintainability (debatable!) of the code. • Using appropriate internal DSLs breaks the program into isolated building blocks. 39

Slide 40

Slide 40 text

© 2013 TomTom. All rights reserved. 40 Thank you Any questions?