The document summarizes a talk given on Scala services frameworks. It introduces Play, HTTP4s, Spray/Akka HTTP, Finch, and Lagom frameworks. It discusses criteria for evaluating frameworks like routing, pluggability, and deployment. It provides high-level overviews of each framework, noting pros and cons. Design, build, support and extension aspects are summarized for each. Finally, it maps frameworks to developer personas and adoption curves, noting where each may be good fits based on priorities like rapid prototyping, functional programming, or enterprise needs.

1. Scala Services in Action
Kingsley Davies Sofia Cole
@kings13y @sofiacole35

2. In the beginning...
K
Who we are and why we are giving this talk..
- Originally asked to review and write pieces for US publisher
- Have a few years experience working with different frameworks in Scala
- Painful Play 2.3 -> 2.5 upgrade. There must be better ways..

3. Mapping all the things
www.sli.do event code: #7277
S
MENTION SLI.DO FIRST SO PEOPLE HAVE TIME TO USE THE CODE
We’ll look at:
- What you expect from microservices
- What you expect from a service framework
- How these frameworks deliver on these expectations
- How they compare in the context of use and users.
- There’s code, but this is more overview

4. What are microservices?
K
● Microservices are all about scale.
● Scale challenges come in several forms, from federating and distributing work,
to deploying and horizontally scaling individual artefacts to just adding specific
features to a system.
● Design and build in terms of functional and isolated components is the basic
goal when implementing a microservices strategy.

5. FP and Microservices
Immutability
Composability
Functions as 1st class citizens
Laziness
Types
=> Isolated and Disposable
=> Composable units
=> Refinement services, Bounded Ctx
=> Serverless
=> ???
K
- ??? might be Session Types in the future ? Remote[T] ?

6. The Pizza of Awesome - microservice delivery
Design Build
Support Extend
K
Microservices lifecycle:
● Design
● Build (+ Deploy)
● Support (+ Monitor)
● Extend

7. Criteria and caveats
Testing
Performance
Documentation support
Pluggability, Deploy ¯_(ツ)_/¯ ….
Routing
Pluggability (auth, persist)
(Un-)Marshalling
Deploy
Monitoring
K
What from a framework
● Routing
● Pluggable auth, persistence etc..
● Marshalling / unmarshalling
● Deployment, and monitoring support
● Cycle time (impedance mismatch from idea to delivery)
● It’s a shallow swim, not a deep dive..
Not covering
● Testing in depth
● Performance

8. Frameworks reviewed
K

9. Play
S
●
●
●
○
○
●
● Play is claims to but Json at the forefront, something we’ll be taking a
look at, and is Restful by default
● Website is good

10. S
CON - Runtime Errors! (GUICE!)

11. S
Con - Compiles after its first request as default - bit annoying

12. }
S
CON - Default application.conf is overwhelming (Slide needs work - basically want to
get across how stupidly long the file is)

13. S
PRO - Super simple to get going - here are the routes as defined in conf/routes

14. S
PRO - Fantastic built in UI

15. S
PRO - Json formatters - easiest one to introduce an optional ID in the json

16. S
… add this to your build.sbt

17. S
And you write your methods straight into your controller!

18. Design Build Support Extend
S
Design - Green with caveat of Guice. Little boilerplate, 0 to service very quickly
Build - If we’ve given Design slack for Guice, I’m inclined not too here. If you go
for Guice, there is going to be work to make sure everyone is up to speed and
comfortable.And you’re saying goodbye to relying on the compiler. There’s also
that the compile time for Play is really quite long. Comes with everything - really
heavy duty.
Support - Production support by Lightbend. Proven to be reliable by it’s use in
many companies using Scala. Dozens of example to download straight from the
website and also uses activator which is a tool to explore tutorials.
Extend - Upgrading from 2.3 - 2.5 Kingley

19. http4s
K
● Functional client/server wrapper around http
● Variety of options to deploy to different containers
● Async using Scalaz tasks and streams
● Typelevel
● v lightweight (similar to Servlets.. Looks slightly close to node js)

20. val service = HttpService {
case GET -> Root / “hello” =>
Ok(“Hello there”)
}
K

21. K
● Service code can end up quite noisy for a single service endpoints.. This is
both good and bad..
● JSON with argonaut and codecs felt a bit too boilerplate like..

22. Design Build Support Extend
K
Design
- Nice and lightweight. Very little ‘noise’ code between design and impl
Build
- Feels very minimal.. Sometimes too minimal.. (like node etc..) Not my
preferred level of abstraction.
Support
- Nice flex around deployment options
- No admin endpoints available out of the box/lib
Extend
- Interesting as small enough to be readily up for extension. Possible
candidate to provide (custom/implicit) types over the wire for client and
server

23. Spray AND akka-http
S
● Decided to review these together because…
○ No roadmap to upgrade spray to scala 2.12… see
■ https://twitter.com/oxbow_lakes/status/796311657
203068928
○ Open-source
○ Layers on top of Akka and Scala
○ Asynchronous
○ Actor-based
○ Fast
○ Lightweight
○ Fault-tolerant
○ Scalable
○ Responsive

24. S
Spray support - saw this page A LOT

25. Spray akka-http
S
Actors are annoying

26. Spray akka-http
S
● Quite similar however you no longer need to deal with the Success and Failure
case that onComplete forces you to do
deal with and the akka http still gives you nice messages if there is an error
● Spent far too long when I first worked with these routes on the implicit
conversion to Json. unlike play, you don’t need to be explicit and say
something like .toJson. Also I found that implicits got mixed up when I was
using different ones in different routes
● Also took too long to figure out how to return futures - spray you have to deal
with them differently - not to worry in akka-http - seems to figure this out by
itself (have a look at this more Sofia!)

27. Spray akka-http
S
● When you miss a tilda something weird happens and isn’t always obvious
before you know
● The route/routes following the missing tilda works but not the one before...

28. Design Build Support Extend
S
Spray …. Then …
Design - Quick and clear on what to do to go from 0 to go. Boiler plate is there
but minimal and once you’re comfortable with nested routes it does speed up
development
Build - Implicits make the routes slightly magic which stalled me for a little while.
People dislike the routes and the runtime tilda problem
Support - Not great, probably the biggest and most important reason not to do it
Extend - Error messages are not always helpful, but once you’re comfortable
with the codebase and framework everything is thumbs up

29. Design Build Support Extend
S
Swap to akka-http which will be much better wooooo good news that’s spray is dying
Design -FAST Quick and clear on what to do to go from 0 to go. Boiler plate is
there but minimal and once you’re comfortable with nested routes it does speed
up development. Also use of magnets to attach behaviour to to routes.
Build - Implicits make the routes slightly magic which stalled me for a little while.
People dislike the routes and the runtime tilda problem
Support - large and active community exists around Akka as well as a number of
dashboard tools be available for akka. Typically use of kamon is wired in for
supporting the production env
Extend - Given the level of commercial and enterprise support for akka,
extension is reasonably simple.

30. Lagom
K
● Framework aggregating a number of other open source
projects to support 4 phases of mircroservices
● Non blocking and asynch
● For distributed systems

31. Play
Akka
Cassandra
(kafka + JDBC)
K
● Play (for routes and guice: DI + Inter Mu Comms)
● Akka (processing: streams, cluster and persistence)

32. Service
Locator & Gateway
Meta vs Impl
Event Sourcing
Command Query
Responsibility Segregation
K
● Service Locator and Gateways
○ Locator: http://localhost:8000/services
○ Gateway on 9000, through which services can be addressed
● Separation of code and meta
○ Distinct separation between implementation code and ‘code about
code’
■ E.g. Descriptor information, service interface code,
Marshalling code etc..
● Event Sourcing
○ State is recreated by replaying a sequence of events
○ Events are atomic
○ No need for persistence impedance mismatch. Objects need not
be persisted.
● CQRS
○ Sorta required for ES, as no data model to readily query
○ Using 1 model to update information and another to read
information
○ Commands affect create, update, delete
○ Different materialised views possible

33. Persistent Entity
Command / State / Event
Commands -> Events -> Persist
K
● Setup of a lagom project
● And overview of main classes that come out of the box used to create
persistence

34. K
● The very morning of the talk, lagom releases it’s (suggested) Scala API!
● Let’s get hacking...

35. Compile time DI w/ cake or Macwire
Stronger Typed APIs
Typeclass Serializers / path params
Macros for service clients
~Kafka as the message broker
K
● Setup of a lagom project with Scala API
● What’s new in the milestone release for Lagom + Scala...

36. http://bit.ly/lagom-scala-M1
K

37. Design Build Support Extend
K
● Still no official Scala API: https://github.com/lagom/lagom/issues/1
Design
● Well thought out patterns, but also slightly constrained for RAD to the
prescribed, opinionated, way. Prob not the right choice to PoC with.
Build
● Low overhead dev setup
● Slightly slow realtime/hot compile+ run feedback..
Support
● Conductr required for Lightbend Monitoring and out of the box deployment..
Non Conductr deployment non-trivial (write a service locator - seen as a time
vs money investment/ trade)..(note K8s support been started here:
https://github.com/lagom/lagom/issues/59 )
● Nice ‘bundle’ abstraction for deployment though..
Extend

38. ● Depends how far deviation differs from out of the box idioms and
supported tools/raodmap
@See:
https://ordina-jworks.github.io/microservices/2016/04/22/Lagom-First-Impressions-and
-Initial-Comparison-to-Spring-Cloud.html#anatomy-of-a-lagom-project

39. Finch
S
● Provides a DSL on top of Twitter’s Finagle webserver framework
● Allows plugging in of different libs for JSON, auth etc, but uses things like
Circe by default
● Models services as something called an Endpoint[T] that can handle
requests and reply with responses monadic
● Functional by design, to allow for AND / OR or mapping of functions over
Endpoints

40. endpoint :: endpoint => endpoint (AND)
endpoint :+: endpoint => endpoint (OR)
endpoint { fn } => endpoint (map)
S
● Composable DSL and functional makes it possible to build API from
reusable building blocks
● Endpoint is the main abstraction. Can be AND / OR / Mapped

41. val retrieveItem = get("items" / uuid) { uuid: UUID =>
Ok(itemRepo.get(uuid))
}
val endpoints = ( retrieveItem :+: createItem)
val service = endpoints.toService
S
URL and method match on get and uuid is extracted and typed
It is then passed in as a function param
DSL provides types like OK (http 200) as a response
Can see how these URLs are combined with OR to make the list of service
endpoints

42. S
+ Admin endpoints provided by com.twitter.server.TwitterServer (~24
endpoints)
+ Simple, composable and typed
+ Easy JSON conversions through circe and shapeless magic..
+ Low cycle time to convert idea to delivery
- If you need to convert from Twitter specific types to standard ones
- Finding people with Finch experience
- More sample apps would be great

43. Design Build Support Extend
S
Design - Very little noise between technical design, requirement and initial
development. The magic of generic types make various conversions trivial
Build - Similarly, little enforcement of specific patterns in place, making
development quick and simple.
Support - Over 2 dozen support admin endpoint available through the Twitter
server, making the application of monitoring on a delivery artefact simple. Only
caveat here being the extensive use of Shapeless can make some diagnosis of
errors a challenge. (Get Dave’s Book!!!!)
Extend - Built as a starting point for extension. Extension tricky due to heavy use
of bespoke Twitter types. Not just out of the box.

44. Activity and Popularity
See: https://scala.libhunt.com/
K
Comparisons taken from: https://scala.libhunt.com/
E.g.
https://scala.libhunt.com/project/lagom/vs/playframework?rel=cmp
-lib

45. Spectrums
L
i
b
r
a
r
y
F
r
a
m
e
w
o
r
k
M
o
n
o
l
i
t
h
Mature / Emerging
[Team / Org]
Flexibility vs Time to market
K
● Lots of ways to measure and compare
● Monolith <> Library.. Size and preconfiguration available.
Frameworks/frameliths in the middle
● Eval against maturity of the team and organisation. Tolerance for risk.
● Is time to market or ability to change a running system most valuable ?
● Monolith style generally quicker to get ot of the door, but debt is in later
modification or isolated scale.

46. Personas
The Hacker:
Bleeding edge tech. Open to risk.
For the love of tech.
The Leader:
Early adopter and evaluator..
Mid risk profile. Tool to get
the job done.
The Follower:
Whatever ‘stack’ the company
has adopted. Low risk. Utili-tech
K
● Introduce our developer persona’s

47. ...on the curve
K
● Developer personas and where they appear on the chasm

48. ...mapping all the things
K
● Mapping our frameworks on the chasm

49. ...good for..
Rapid Prototyping / Mocks
Functioning Functional
The Enterprise
Next Gen
Spray ?
NG Types ?
K
● Considerations for the system architect/delivery lead/manager/CTO and
how they map to a library choice.
● Mocks -> http4s
● Functional -> Finch
● Enterprise -> Play
● Next Gen enterprises -> Lagom
● Where does Spray / Akka-http fit in ? (note, akka / akka-http often used
under the covers in Lightbend stacks)

50. Conclusion
FP => Microservices isomorphism
Monoliths / Frameliths => bootstrap speed vs future agility
More planes in the blue skies, More platforms onto the boats
Over the wire types => FTW
Business ⇔ Tech ⇔ People => Decisions
K
- Some level of mapping or isomorphism between FP and
microservices
- Monoliths (frameliths) are quick to get started, but their agility
can atrophy quickly
- More ‘practical’ blogs, samples and decision trees required
- Watch out for Over the wire Types! OTWT => FTW!

51. Thanks, Links and Questions
THANK YOU!!!
Dave Gurnell & Team Underscore & ITV
● @kings13y / @sofiacole35
● http://breakpointradio.net
● http://underscore.io/
● www.sofiacole.com
● http://bit.ly/finch-101
● http://bit.ly/finch-to-1
● http://bit.ly/lagom-scala-ex
● http://bit.ly/onthetypelevel
● http://bit.ly/opencliptroot
● http://bit.ly/sesstypes
● http://bytes.schibsted.com/109/
● http://bit.ly/shapelessPRs
Be Nice :-)
S
My blog posts that will be going up over the coming weeks
+ source code in github!
+ slides!
+ KD blogpost on Lagom 1.3.0-M1 the Scala edition on _ blog !
Follow #scalax or podcast / tweets for notifications!