Hi!
While connecting our game’s Nakama balances to another (blockchain-dependent) system, turned out there is no obvious way to monitor Nakama’s account wallet updates.
I wonder if there’s a way or a nice workaround you could suggest?
Nikita
Wallet updates are always authoritative and needs to run from within a RPC. You can implement any type of observable patterns in your own RPC code. Would this help?
2 Likes
Hey! I understand it, however we’re developing some kind of a Go common module for all of our games, so I wanted to use standard APIs in our JS game code to change balances and then just monitor it with Go. But it does not seem like the best idea, will try to implement something smarter.
Random thought: would be still cool if there was some kind of an internal bus available for communication/queues inside the Runtime Framework of Nakama
We’ve considered an Event Bus observer/observable pattern in Nakama in the past. We’ve settled on not adding this at Nakama layer due to the complexity added to the learning curve for developers and so many variations and indirections it can bring in (especially for lesser experienced developers).
We’ve implemented this pattern in Hiro where we are in much more control of the way the code is written and exposure is measured.
1 Like
However, what about go-lua-js calls? For now I have to make a http request from JS to Go, which seems not that beautiful. Do you plan on implementing some kind of a system for this? I wonder if I could contribute to Nakama myself, if you don’t have anything against this idea?
We’ve considered a way to have Go/Lua/JS interop calls. This is not easy to do - there are memory allocation considerations, there are type safety/hinting considerations (or lack of), and referencing VMs that may have gone away issues. By all means, if you think you can open a PR that covers it, I’m all for it, but you may hit some very difficult challenges that we’ve not been able to solve ourselves 
1 Like