jroper on template
Updating current documentation Updating 1.6.x documentation Updating 1.5.x documentation (compare)
ignasi35 on 1.6.x
build-link, play, play-ahc-ws, … Sync versions (cherry picked f… Update docs/build.sbt and 1 more (compare)
ignasi35 on bp
My team has been really fond of something like this:
api ├── MyService.scala ├── domain │ └── package.scala ├── events │ └── package.scala └── commands └── package.scala
which is really organizationally nice... not sure if that's how opinionated Lagom wants to be, though.
Does it make sense to prescribe/recommend a repo structure?
I have to write a blog post about that
implfor each services
messagesdon’t know each others
HandlerDeffor HTTP filter. :pray:
MetricsServicebind by implementation class?
MetricsServicemay be removed some time in the future. It’s a service providing per-instance information so it’s weird to read that info via RPC (where you usually want to treat all instances/nodes equally). Instead, metrics should be pushed to an external aggregator to create some form of dashboard.
MetricsService. Now we do the following. We subscribe to the stream of data from
MetricsServiceand push data to an external
MetricRegistry(+ graphite reporter).
validateDependencyWhitelistworked locally, but yeah, I was considering that too.