certusone
/
cosmos-sdk
mirror of https://github.com/certusone/cosmos-sdk.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

ADR-031: elaborate consequences and encapsulation of module client-se… (#7839) 

* ADR-031: elaborate consequences and encapsulation of module client-server implementation

* Update docs/architecture/adr-031-msg-service.md

Co-authored-by: Aaron Craelius <aaron@regen.network>

Co-authored-by: Aaron Craelius <aaron@regen.network>
This commit is contained in:
Robert Zaremba 2020-11-19 00:11:04 +01:00 committed by GitHub
parent 35183a37e6
commit fe58ee9951
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 15 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
docs/architecture/adr-031-msg-service.md
View File

@ -218,17 +218,25 @@ Separate handler definition is no longer needed with this approach.
## Consequences ## Consequences
This design changes how a module functionality is exposed and accessed. It deprecates the existing `Handler` interface and `AppModule.Route` in favor of [Protocol Buffer Services](https://developers.google.com/protocol-buffers/docs/proto3#services) and Service Routing described above. This dramatically simplifies the code. We don't need to create handlers and keepers any more. Use of Protocol Buffer auto-generated clients clearly separates the communication interfaces between the module and a modules user. The control logic (aka handlers and keepers) is not exposed any more. A module interface can be seen as a black box accessible through a client API. It's worth to note that the client interfaces are also generated by Protocol Buffers.
This also allows us to change how we perform functional tests. Instead of mocking AppModules and Router, we will mock a client (server will stay hidden). More specifically: we will never mock `moduleA.MsgServer` in `moduleB`, but rather `moduleA.MsgClient`. One can think about it as working with external services (eg DBs, or online servers...). We assume that the transmission between clients and servers is correctly handled by generated Protocol Buffers.
Finally, closing a module to client API opens desirable OCAP patterns discussed in ADR-033. Since server implementation and interface is hidden, nobody can hold "keepers"/servers and will be forced to relay on the client interface, which will drive developers for correct encapsulation and software engineering patterns.
### Pros ### Pros
- communicates return type clearly - communicates return type clearly
- manual handler registration and return type marshaling is no longer needed, just implement the interface and register it - manual handler registration and return type marshaling is no longer needed, just implement the interface and register it
- some keeper code could be automatically generate, this would improve the UX of [\#7093](https://github.com/cosmos/cosmos-sdk/issues/7093) approach (1) if we chose to adopt that - communication interface is automatically generated, the developer can now focus only on the state transition methods - this would improve the UX of [\#7093](https://github.com/cosmos/cosmos-sdk/issues/7093) approach (1) if we chose to adopt that
- generated client code could be useful for clients - generated client code could be useful for clients and tests
- dramatically reduces and simplifies the code
### Cons ### Cons
- supporting both this and the current concrete `Msg` type approach simultaneously could be confusing - supporting both this and the current concrete `Msg` type approach simultaneously could be confusing
(we could choose to deprecate the current approach) (we could choose to deprecate the current approach)
- using `service` definitions outside the context of gRPC could be confusing (but doesn’t violate the proto3 spec) - using `service` definitions outside the context of gRPC could be confusing (but doesn’t violate the proto3 spec)
## References ## References
- [Initial Github Issue \#7122](https://github.com/cosmos/cosmos-sdk/issues/7122) - [Initial Github Issue \#7122](https://github.com/cosmos/cosmos-sdk/issues/7122)