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

Modular server #8208

Closed
4 tasks
fedekunze opened this issue Dec 21, 2020 · 5 comments
Closed
4 tasks

Modular server #8208

fedekunze opened this issue Dec 21, 2020 · 5 comments
Labels
C:server/2 Issues related to server/v2 T:feature-request

Comments

@fedekunze
Copy link
Collaborator

Summary

Turn the Server and Config types into interfaces that allow for app customization and extensibility.

Problem Definition

The current Server and Config are structs that are not extensible for applications that need to define additional server configurations, such as Ethermint with JSON-RPC and the Ethereum Websocket.

Proposal

Create an additional interface that wraps the current server and config types and functionalities

type SDKServer interface {
	Ctx() client.Context
	GetRouter() *mux.Router
	GetGRPCGatewayRouter() *runtime.ServeMux

	Start(config.ServerConfig) error
	Stop() error
}


type ServerConfig interface {
	GetBaseConfig() BaseConfig
	GetAPIConfig() APIConfig
	GetGRPCConfig() GRPCConfig
	GetTelemetryConfig() telemetry.Config
	GetStateSyncConfig() StateSyncConfig
}

Then the application interface will result in:

// Application defines an application interface that wraps abci.Application.
// The interface defines the necessary contracts to be implemented in order
// to fully bootstrap and start an application.
type Application interface {
      abci.Application
      
      RegisterAPIRoutes(api.SDKServer, config.ServerConfig)
      
      // RegisterGRPCServer registers gRPC services directly with the gRPC
      // server.
      RegisterGRPCServer(grpc.Server)
      
      // RegisterTxService registers the gRPC Query service for tx (such as tx
      // simulation, fetching txs by hash...).
      RegisterTxService(clientCtx client.Context)
      
      // RegisterTendermintService registers the gRPC Query service for tendermint queries.
      RegisterTendermintService(clientCtx client.Context)
}

For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
@alexanderbez
Copy link
Contributor

  • Why does ServerConfig need to have all those APIs? it makes the interface pretty rigid. Why can it not just have a simple Get(string) interface {}?
  • Why do we have the Ctx() client.Context API in the SDKServer interface? This seems like a codesmell.
  • RegisterTendermintService doesn't line up with what is actually being done.

All in all, I support the idea behind this. I just need the APIs and abstractions need a bit more thought. Also, a proposal should be written as an ADR.

@okwme
Copy link
Contributor

okwme commented Dec 22, 2020

What's the difference between this and adding a new command to the daemon init that starts a custom server? This could take place inside of /cmd/{appName}/cmd/root.go and use rootCmd.AddCommand() with reference to the custom API and port, right?

@alexanderbez
Copy link
Contributor

Not quite @okwme, @fedekunze is referring to how we can make the app configuration extensible with programmatic APIs.

@tac0turtle
Copy link
Member

im a fan of this and when we adopt other consensus or sequencer tech we will need something like this as well.

@tac0turtle
Copy link
Member

closing this in favour of #18282

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C:server/2 Issues related to server/v2 T:feature-request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants