2. Some points mentioned in the
“The Art of Decomposing Monoliths” talk:
*Akka vs Microservices
*proper contract testing
*forward/backward compatibility
*proper JSON marshalling
*DRY
23. API First
Document and
peer review API
before writing a
single line of code
Ideally, generate either
your server interfaces
or your test data (or
both) from the spec
26. DRY
Dave Thomas
Most people take DRY to mean you shouldn't duplicate code.
That's not its intention. The idea behind DRY is far grander
than that. DRY says that every piece of system knowledge
should have one authoritative, unambiguous representation.
35. REST
• Client-Server
• Stateless
• Cacheable
• Layered System
• Uniform Interface
• Identification of resources
• Manipulation of resources through these representations
• Self-descriptive messages
• Hypermedia as the engine of application state
37. REST APIs must be
hypertext-driven
• “A REST API should spend almost all of its descriptive effort in defining the
media type(s) used for representing resources and driving application state,
or in defining extended relation names and/or hypertext-enabled mark-up for
existing standard media types.”
Roy T. Fielding
51. • Easy to use
• Human readable
• Widest adoption
• Open Source
• Scala and Java
• Dynamic recompilation / Hot reload
• Asynchronous IO
• Easy to use
52. • URI path definitions (supports parameterisation and templating)
• URI parameter definitions
• Response definitions
• Scheme definitions
• MIME type definitions
• Primitive datatypes
• Complex datatypes
• Structural constraints
• Value constraints
• Security constraints
• Tags
• Vendor extensions
56. [A] constructive approach to the problem of program
correctness [is] a usual technique to make a program and
then to test it. But, program testing can be a very effective
way to show the presence of bugs, it is hopelessly
inadequate for showing their absence. The only effective
way to raise the confidence level of a program significantly
is to give a convincing proof of its correctness.
-- Edsger, Wybe Di jkstra, ACM Turing Lecture, The Humble Programmer, 1972
58. Types are specifications of possible values complying to that Type
Types describe the rules that values must comply to
A possibility to generate ranges of data values for given Types
John Hughes, Haskell’s Quick Check
59. Boolean: True or False
Equality: Equal or Not Equal
Ordering: Greater, Equal or Less
Provable