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 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
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.