Decompose BaseApp into Middleware

[aaronc]

This seems like the next logical step after #9585 and would make the SDK much more modular and configurable at the ABCI protocol level. I don't see a super high priority for this, but just documenting the overall gist.

The basic idea would to have a type Application which is basically the abci.Application interface with context.Context params plus pure functional ApplicationMiddleware.

type ApplicationMiddleware func(Application) Application

type Application interface {
	// Info/Query Connection
	Info(context.Context, RequestInfo) ResponseInfo                // Return application info
	SetOption(context.Context, RequestSetOption) ResponseSetOption // Set application option
	Query(context.Context, RequestQuery) ResponseQuery             // Query for state

	// Mempool Connection
	CheckTx(context.Context, RequestCheckTx) ResponseCheckTx // Validate a tx for the mempool

	// Consensus Connection
	InitChain(context.Context, RequestInitChain) ResponseInitChain    // Initialize blockchain w validators/other info from TendermintCore
	BeginBlock(context.Context, RequestBeginBlock) ResponseBeginBlock // Signals the beginning of a block
	DeliverTx(context.Context, RequestDeliverTx) ResponseDeliverTx    // Deliver a tx for full processing
	EndBlock(RequestEndBlock) ResponseEndBlock       // Signals the end of a block, returns changes to the validator set
	Commit(context.Context) ResponseCommit                          // Commit the state and return the application Merkle root hash

	// State Sync Connection
	ListSnapshots(context.Context, RequestListSnapshots) ResponseListSnapshots                // List available snapshots
	OfferSnapshot(context.Context, RequestOfferSnapshot) ResponseOfferSnapshot                // Offer a snapshot to the application
	LoadSnapshotChunk(context.Context, RequestLoadSnapshotChunk) ResponseLoadSnapshotChunk    // Load a snapshot chunk
	ApplySnapshotChunk(context.Context, RequestApplySnapshotChunk) ResponseApplySnapshotChunk // Apply a shapshot chunk
}

For ADR-040/SMT migration, the provision of a root store could then become something that store middleware deals with and this could be swapped out for the old IAVL store or some other implementation.

@fdymylja @jgimeno I know deprecating BaseApp is something you two have been looking into. Wonder if you have any thoughts. @ethanfrey wonder if you have any experiences to share from your experiences with Weave.

[ethanfrey]

type ApplicationMiddleware func(Application) Application seems too high level for me.

One could wrap an entire application embedding an Application and overriding as needed

type MyApp struct {
  Application
  otherField OtherType
}

👍 Making Application an interface makes sense here, so the consumers don't care if it has been wrapped or not.

🤷 However, the pattern as "ApplicationMiddleware" seems not so interesting to me. More like I would wrap it one time for one specific purpose for my custom blockchain if I want to do some super-special customisation.

I think the more interesting part is allowing BaseApp (or whatever you rename the default implementation of Application) to be more composable as in #9934. Changing Deliver/Check/Query should not require copying BaseApp into your application and modifying it and then realise so much other code only accepts cosmos-sdk/app.BaseApp and not your implementation.

I would focus the middleware and customisation to fit inside BaseApp and at a lower level than the abci interface, so we can pass sdk.Context around with all the storage and such. This is much more powerful than the abci interface, where a wrapper has no access to the lower level storage implementation. I have only come up with a handful of ideas in the last 4 years that work on that level. Good to allow them, but I would not focus the architecture around this.

[robert-zaremba]

Wrapping is more restricted - you can't easily reuse and compose the "wraps" as you like.

[robert-zaremba]

pure functional ApplicationMiddleware

Do you mean that ApplicationMiddleware can't make any side effect nor it's own state?

[robert-zaremba]

This is a very big interface. Why not composing on the smaller levels (eg snapshot, commit, ...)?

Alternative

I propose to only have a smaller / dedicated interfaces:

type TxHandler interface {   // This one we have
	CheckTx(context.Context, RequestCheckTx) ResponseCheckTx // Validate a tx for the mempool
	DeliverTx(context.Context, RequestDeliverTx) ResponseDeliverTx    // Deliver a tx for full processing
}

type SnapshotMiddleware interface {
	ListSnapshots(context.Context, RequestListSnapshots) ResponseListSnapshots                // List available snapshots
	OfferSnapshot(context.Context, RequestOfferSnapshot) ResponseOfferSnapshot                // Offer a snapshot to the application
	LoadSnapshotChunk(context.Context, RequestLoadSnapshotChunk) ResponseLoadSnapshotChunk    // Load a snapshot chunk
	ApplySnapshotChunk(context.Context, RequestApplySnapshotChunk) ResponseApplySnapshotChunk // Apply a shapshot chunk
}

type QueryHandler interface {
	Query(context.Context, RequestQuery) ResponseQuery             // Query for state
}

[ethanfrey]

I fully support replacing 90% of BaseApp with decorators (which take over AnteHandler and much of the orchestration logic). This is what I did in weave and it worked great as we added lots of application logic and iterated on it.

The proposed decomposition seems to be more theoretically motivated and I have not seen some clear use cases, where it will provide functionality easier than could be achieved some other way. I would like to see some concrete examples of what you want to achieve.

Wrapping more restricted - you can't easily reuse and compose the "wraps" as you like

It is good to restrict APIs in some ways if you can make them work better for 99% of the use cases. So purely "more flexible" only makes sense if there is a clear need for that flexibility

[robert-zaremba]

I fully support replacing 90% of BaseApp with decorators

Totally. We are handling this also in the App Wiring WG.