jroper on template
Updating latest documentation (compare)
mergify[bot] on master
Update okio to 2.7.0 Merge pull request #2937 from s… (compare)
allIssuesdoesn't actually capture all issues of a driver -- it captures all issues of a run
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).