Core
Ironically the core know how to do everything but it is made so abstract that as it unable to do anything. So to make @shinka-rpc be able to do things, you have to pass the transport — commonly very small function, returning 2 functions: send and close, and subscribing the bus instance to onMessage.
Structure of @shinka-rpc
There are main components of @shinka-rpc
Client and Server
The only difference between Server and Client that Server accepts multiple connections, but the Client accepts only one
TIP
In some cases like @shinka-rpc/dedicated-worker both sides accepts only one connection. Who of them is Server?
Server can initialize connections by itself, so reverse-server and hybrid scenarios are also available
Registry
This is the way how to control client's connect and disconnect