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

go-wechaty implementation wechaty-puppet-hostie discussion. #22

Open
dchaofei opened this issue Apr 13, 2020 · 3 comments
Open

go-wechaty implementation wechaty-puppet-hostie discussion. #22

dchaofei opened this issue Apr 13, 2020 · 3 comments
Labels
documentation Improvements or additions to documentation question Further information is requested
Milestone

Comments

@dchaofei
Copy link
Collaborator

Question 1: Is wechaty-puppet-hostie acting as a client? Wechaty-puppet- * can be connected via wechaty-puppet-hostie?

@huan
Copy link
Member

huan commented Apr 13, 2020

Thanks for asking this question, it's very important for us to understand the Wechaty architecture so that we can start designing our Go/Python/Java Wechaty code base.

Short answers to your questions:

  1. Is wechaty-puppet-hostie acting as a client?

    Yes, our Go Wechaty should be backed by the wechaty-puppet-hostie (in Go of course), which will connect to the GRPC service as a client.

  2. Wechaty-puppet- * can be connected via wechaty-puppet-hostie?

    Yes. wechaty-puppet-* are all child class of wechaty-puppet abstract class, and any wechaty-puppet class can be served as a GRPC service by the Wechaty framework.

As we already have a big picture from the whole Wechaty system from wechaty/wechaty#1927 , lets zoom in and have a look on top of our GRPC service with our Go implementation:

  +-------------------------------------------------------+
  |                                                       |
  |  1.           Wechaty(Go, Python, Java)               |
  |                                                       |
  +-------------------------------------------------------+

  +-------------------------------------------------------+
  |  2.            Wechaty Puppet Abstract                |
  |                                                       |
  |                    (wechaty-puppet)                   |
  +-------------------------------------------------------+

  +-------------------------------------------------------+
  |  3.             Wechaty Puppet Hostie                 |
  |                                                       |
  |                (wechaty-puppet-hostie)                |
  +-------------------------------------------------------+

+------------------- 4.  @chatie/grpc  ----------------------+

1. Go Wechaty

Map to: TypeScript Wechaty

This is what we are doing in this repository.

Wechaty will provide all the APIs to the end-user, with underlying support from the puppet abstraction.

2. Go Wechaty Puppet Abstract Class

Map to: TypeScript Wechaty Puppet Abstraction

This is the puppet abstraction interface for Wechaty, which will help us to define the protocol between the Wechaty with all the different Puppet providers.

In Go/Python/Java, we only need to implement the wechaty-puppet-hostie, which will connect our puppet abstraction to the GRPC service.

Note: It will be best if this module can be synced with the TypeScript abstraction automatically because:

  1. the TypeScript Wechaty Puppet Abstraction will hold the golden truth
  2. the TypeScript Wechaty Puppet Abstraction will be expected to change/refactor frequently in the future

We have already known a tool which can sync the data schemas from @suntong at #26

3. Go Wechaty Puppet Hostie

Map to: TypeScript Wechaty Puppet Hostie Client

A module with the name wechaty-puppet-hostie is for implementing the puppet abstraction by connecting to our GRPC service from the Wechaty framework.

When we are working in Go, we can focus on the client-side because the server-side will be provided from the TypeScript ecosystem, which means we can be supported by all the Protocols from the powerful Wechaty Puppet Providers, like:

  1. PC Windows - wechaty-puppet-donut
  2. Pad - wechaty-puppet-padplus
  3. Mac - wechaty-puppet-macpro
  4. etc. (learn more from our Puppet Directory)

4. GRPC Service

We already have our Go GRPC module at https://github.com/wechaty/go-grpc today (appreciate for your PR), and it will be automatically updated with the version tag whenever our chatie/grpc repo updated.

Conclusion

The Wechaty API should be implemented first, then the Wechaty Puppet Abstraction API second.

After we have both Wechaty API and Puppet Abstraction, then we can build our Wechaty Puppett Hostie Client based on them.

I hope my explanation will be helpful, please feel free to let me know if you have any questions.

@huan huan added documentation Improvements or additions to documentation question Further information is requested labels Apr 13, 2020
@dchaofei
Copy link
Collaborator Author

Thank you for your answer.

@huan huan pinned this issue Apr 17, 2020
@huan
Copy link
Member

huan commented Apr 20, 2020

Cross-post from #32 (comment)

I believe we should make the import chain rule more clearer: the wechaty-puppet-hostie should rely as much as possible on the github.com/wechaty/go-wechaty/wechaty-puppet and github.com/wechaty/go-grpc because they have different responsibilities.

  1. wechaty-puppet-hostie should implement the interface from github.com/wechaty/go-wechaty/wechaty-puppet, and connect those API from the interface, to the grpc service via github.com/wechaty/go-grpc
  2. github.com/wechaty/go-wechaty/wechaty-puppet should only define an interface for all puppets. (A Abstract Class in OOP, a Protocol in ObjC, or Interface in Go(?))
  3. github.com/wechaty/go-grpc should be auto-generated from the protocol buffer, so that it can provide the Go API interface directly to our puppet provider.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants