chore/msp-example: refactor to align with service structure best practices#62954
Conversation
| "github.com/sourcegraph/sourcegraph/lib/managedservicesplatform/runtime" | ||
|
|
||
| "github.com/sourcegraph/sourcegraph/cmd/msp-example/internal/example" | ||
| "github.com/sourcegraph/sourcegraph/cmd/msp-example/service" |
There was a problem hiding this comment.
I was kinda expecting this?
| "github.com/sourcegraph/sourcegraph/cmd/msp-example/service" | |
| "github.com/sourcegraph/sourcegraph/cmd/msp-example/internal/service" |
There was a problem hiding this comment.
Yeah I thought about that but I think it's a top-level construct and I want to avoid nesting too much, perhaps. That way internal/foobar still has meaning and it's clear it's not on the same level as internal/service
There was a problem hiding this comment.
That way
internal/foobarstill has meaning and it's clear it's not on the same level asinternal/service
I think that's not a useful "clear" signal than "service" is internal to the MSP service, should not be used by any others 🤔
There was a problem hiding this comment.
The way I think about it, "service" is effectively the entrypoint to all the stuff in internal/, i.e.
Command -> Service -> Internals
So the exported Service isn't useful in practice, but in terms of hierarchy I think it has an important place as "not just another internal package"
There was a problem hiding this comment.
OK I think it just a bit weird in a monorepo setup, where cmd/ is the top-level directory that includes everything.
Looking at on SAMS repo, for example.
cmd/accounts-servver imports backend/service seems making sense, and actually required because cmd can't import backend/internal/service.
There was a problem hiding this comment.
Yeah, for a standalone repo case it would be:
cmd/my-service <- command
service/... <- entrypoint
internal/... <- internal implementation
In monorepo:
Outside monorepo a similar unnested structure aligns with this as well:
Test plan
Basic example builds and runs:
sg run msp-example