-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add core module API #12239
feat: add core module API #12239
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Co-authored-by: Aleksandr Bezobchuk <alexanderbez@users.noreply.github.com>
Co-authored-by: Aleksandr Bezobchuk <alexanderbez@users.noreply.github.com>
"google.golang.org/protobuf/runtime/protoiface" | ||
) | ||
|
||
type GenesisSource interface { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: godocs on interfaces and their methods
use_package: { | ||
name: "example" | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this for app wiring? What does this mean?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's sort of informational for now, but eventually the idea is that it helps clients know about protobuf package revisions (for instance when we add comments like Since 0.46
in .proto files). See https://github.com/cosmos/cosmos-sdk/blob/main/proto/cosmos/app/v1alpha1/module.proto#L25-L81.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Who and where is going to check this? Do we really need this in proto? It seams it's Cosmos SDK Go implementation specific, so why not using Go directly rather than going through proto?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm giving a concept ACK, namely the part where we have a core
API for the sdk which aims to be stable, and extensible/customizable runtimes that satisfy the core
API.
I'm still not convinced about a lot of the APIs (e.g. tiny services, handlers vs extension interfaces, overridable gas meters...), but I guess we can address those separately.
I can also approve the accompanying ADR, whichever you want to see go in first @aaronc.
core/appmodule/service.go
Outdated
event.Service | ||
blockinfo.Service | ||
gas.Service | ||
RootInterModuleClient |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there value in creating these subservices separately?
In practice, for a smooth transition, I envision module developers (including us) just replacing sdk.Context
with this bundle service. We can also remove a lot of core/*/service.go
packages, and just have a single one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah it might be possible to have one meta service. I think it is still nice to have clear separation of concerns and separate packages.
I hear and understand this apprehension. @aaronc is there a way we can go with a more minimal API first and not introduce types/APIs which we don't immediately need? Like we can keep things around genesis stuff and the ABCI boundary. |
We can work on things one by one if that is easier. In that case, doing the micro-service approach actually makes sense because we can implement one by one until we have the full |
@aaronc yes, let's start with a subset of the required/necessary APIs introduced in this PR 🙏 |
@AmauryM @alexanderbez I updated this PR to use extension interfaces instead of handlers based on discussions with @AmauryM related to #13281. I will start introducing pieces of this one by one so we can gradually build consensus on the right approach, but I want to keep the full picture here for reference. |
@aaronc so is this R4R again? |
seems like the idea is to piece meal it into main instead of one huge merge? if so can we close this for now |
Yes, the idea is to piece meal it into main. I still think it's useful to at least have this in draft to refer to in those smaller PRs see the big picture. I think small PRs like #13607, while maybe the right stepping stone, don't convey enough context on their own. |
type GenesisSource interface { | ||
ReadMessage(protoiface.MessageV1) error | ||
OpenReader(field string) (io.ReadCloser, error) | ||
ReadRawJSON() (json.RawMessage, error) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is ReadMessage
and ReadRawJSON
going to read next record or all records? If latter, then we should have kind of an iterator pattern:.
// NOTE: If new core services are provided, they shouldn't be added to this | ||
// interface which would be API breaking, but rather a cosmossdk.io/core/appmodule/v2.Service | ||
// should be created which extends this Service interface with new services. | ||
type Service interface { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this represents an App
?
} | ||
|
||
// Iterator is an alias db's Iterator for convenience. | ||
type Iterator = dbm.Iterator |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should avoid creating aliases , unless needed for refactoring.
use_package: { | ||
name: "example" | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Who and where is going to check this? Do we really need this in proto? It seams it's Cosmos SDK Go implementation specific, so why not using Go directly rather than going through proto?
Description
Replaces #11340
ADR in #12972
This PR adds a new module
core
with a basic API for building modules with the new app wiring with zero implementation and an example module using it (seecore/internal/example
). It is intended to be an API with a smaller surface area exposed than what's currently insdk.Context
,types/
,store/
etc. that apps can depend on not changing even if the underlying implementation changes substantially.It attempts to cover very high-level module needs (for 95% of use cases) for:
All context access is through the go standard
context.Context
so that each component doesn't need knowledge of the other things that might be in the context (unlike our currentsdk.Context
). The API is intended to be simple and independent of any particular Tendermint release (with lower-level APIs available for code that needs more direct Tendermint interaction).It should be pretty straightforward for the current
runtime
module to implement all of the above interfaces on top of the existingsdk.Context
and kv-store keys. This allows future runtime and store layers to change the underlying implementation substantially (i.e. ABCI++ or store/v2) without any API breakage for modules depending on core.I didn't get to genesis handling or any CLI stuff and intend to do that in follow-up PRs.
Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...
!
to the type prefix if API or client breaking changeCHANGELOG.md
Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...
!
in the type prefix if API or client breaking change