You say “The code you deploy with the server can be used immediately by clients, allowing you to change behavior on the fly and add new features faster.” At Introduction - Heroic Labs Documentation.
Is this true and how to achieve it?
I am currently using TypeScript to write modules.
Hello @devantti,
This is correct, with each new deployment you can introduce changes to your custom code and/or Nakama version upgrades, which can expose new RPCs or behaviour changes with each new deployment.
How you handle the switch-over during a deployment will depend on your setup. For easy deployments with zero downtime consider using Heroic Cloud where High Availability is automatically enabled on deployments with 2 or more nodes.
Best.
Thanks for quick reply.
How would it be handled without Heroic Cloud? My game is still in early stage of development so it is not unfortunately an option.
Unfortunately we can’t give support to deployments outside of Heroic Cloud as there’s too many variables to account for depending on how you’ve set up your deployment.
Typically you’d have the server behind a load balancer and you’d swap it out with the new version. If you only have one node some amount (however small) of downtime is expected.
The clients would also need to handle socket reconnections, and if you’re using Authoritative Matches, you’d either need to persist their state to restore it, or stop accepting new matches and wait for all of them to complete before you deploy the new version of the server.
I would also write a suggestion/topic to keep on mind if you are developing an update to a game, and it needs to go through review/verification process and in that time you did core changes to backend api, or even changed structure of some packets, because of the review and since you don’t know when review will pass, you will need to keep at least 2 versions up, old one and the one being reviewed.
In Nakama, we had to deal with this problem, especially with apple, and we did it on a way by having backward compatibility with server/api based on client request versions, and for rpc-s saddly since underlying /v/ params are already used by nakama, we had to append _v<> to our rpc calls, not elegant solution but it works 
Ok, thanks. Unfortunately that doesn’t sound much like changing behavior on the fly to me. I was hoping that it would work for example just by adding a new module and server would just load it.
Thanks @Eatos for your insights.