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/
jroper on template
Updating 1.5.x documentation (compare)
octonato on bp
use ClassLoaderLayeringStrategy… (compare)
jroper on template
Updating latest documentation Updating 1.5.x documentation (compare)
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).
validateDependencyWhitelist
worked locally, but yeah, I was considering that too.