Discussion of Lagom project development: https://github.com/lagom/.github/blob/master/CONTRIBUTING.md | Use lagom/lagom channel for general discussion. | Code of Conduct: https://www.lightbend.com/conduct | Forums: https://discuss.lagomframework.com | Commercial support from https://www.lightbend.com/
ignasi35 on bump-sbt-150
Comment out the JDK11 docs gene… (compare)
ignasi35 on bump-sbt-150
Comment out the JDK11 docs gene… (compare)
allIssues
doesn'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
api
and impl
for each services
api
depends on dto
and messages
but dto
and messages
don’t know each others
HandlerDef
for HTTP filter. :pray:
MetricsService
bind by implementation class?MetricsService
by implementation is normal case.
MetricsService
may 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 MetricsService
and push data to an external MetricRegistry
(+ graphite reporter).