Skip to content
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

Closed
wants to merge 50 commits into from
Closed

feat: add core module API #12239

wants to merge 50 commits into from

Conversation

aaronc
Copy link
Member

@aaronc aaronc commented Jun 13, 2022

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 (see core/internal/example). It is intended to be an API with a smaller surface area exposed than what's currently in sdk.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:

  • store
  • events
  • block height, time, hash
  • gas
  • msg & query server registration
  • begin & end blockers

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 current sdk.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 existing sdk.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...

  • included the correct type prefix in the PR title
  • added ! to the type prefix if API or client breaking change
  • targeted the correct branch (see PR Targeting)
  • provided a link to the relevant issue or specification
  • followed the guidelines for building modules
  • included the necessary unit and integration tests
  • added a changelog entry to CHANGELOG.md
  • included comments for documenting Go code
  • updated the relevant documentation or specification
  • reviewed "Files changed" and left comments if necessary
  • confirmed all CI checks have passed

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

  • confirmed the correct type prefix in the PR title
  • confirmed ! in the type prefix if API or client breaking change
  • confirmed all author checklist items have been addressed
  • reviewed state machine logic
  • reviewed API design and naming
  • reviewed documentation is accurate
  • reviewed tests and test coverage
  • manually tested (if applicable)

@aaronc aaronc marked this pull request as ready for review June 13, 2022 21:30
@aaronc aaronc requested a review from a team as a code owner June 13, 2022 21:30
Copy link
Member

@tac0turtle tac0turtle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

core/blockinfo/service.go Outdated Show resolved Hide resolved
core/blockinfo/service.go Outdated Show resolved Hide resolved
core/appmodule/handler.go Outdated Show resolved Hide resolved
aaronc and others added 4 commits June 14, 2022 13:13
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 {
Copy link
Contributor

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

Comment on lines +13 to +15
use_package: {
name: "example"
}
Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Collaborator

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?

Copy link
Contributor

@amaury1093 amaury1093 left a 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.

event.Service
blockinfo.Service
gas.Service
RootInterModuleClient
Copy link
Contributor

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.

Copy link
Member Author

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.

@alexanderbez
Copy link
Contributor

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

@aaronc
Copy link
Member Author

aaronc commented Oct 12, 2022

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 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 appmodule.Service ready. #13519 introduces the ADR 033 part of this API. We could maybe even start with that?

@alexanderbez
Copy link
Contributor

@aaronc yes, let's start with a subset of the required/necessary APIs introduced in this PR 🙏

@aaronc
Copy link
Member Author

aaronc commented Oct 20, 2022

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

@alexanderbez
Copy link
Contributor

@aaronc so is this R4R again?

@tac0turtle
Copy link
Member

seems like the idea is to piece meal it into main instead of one huge merge? if so can we close this for now

@aaronc
Copy link
Member Author

aaronc commented Oct 21, 2022

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.

@aaronc aaronc marked this pull request as draft October 21, 2022 18:05
type GenesisSource interface {
ReadMessage(protoiface.MessageV1) error
OpenReader(field string) (io.ReadCloser, error)
ReadRawJSON() (json.RawMessage, error)
Copy link
Collaborator

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 {
Copy link
Collaborator

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
Copy link
Collaborator

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.

Comment on lines +13 to +15
use_package: {
name: "example"
}
Copy link
Collaborator

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?

@aaronc aaronc closed this Dec 1, 2022
@tac0turtle tac0turtle deleted the aaronc/core-api branch April 14, 2023 10:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants