sadief
commented
1 year ago Hi @cchimbooo! I'm so sorry for the very late reply to this! My apologies.
That's a great question - I didn't get the chance to add a code example of this, but I have had a couple questions on it so maybe if I have some time I will add one.
But to answer your question, at least the way that we've done it is by having the goroutines as standalone functions that have their own separate deployment files.
For example, in the coffee shop analogy, if we had the go SteamMilk and go MakeEspresso functions, I'd have two deployment files for each, and they would deploy independently.
That of course raises your question which is about communicating through pods, or the state management. Since we had fairly straightforward, isolated actions that didn't depend on any other actions, we use a shared database to track the state management (eg. you might have a table of all the coffees that need to be made with a milk, and espresso column, and each time a SteamMilk completed, it updates the milk column to DONE or something like that, and then you might have another goroutine that continually checks that table for complete coffees and then serves them up). This works nicely for something that can be 100% run independently, but when you start needing goroutines to communicate with each other directly you might need to use channels for that, or some other queing/request method.
Let me know if that helps! Always happy to chat more :)
Hey, I just finished watching your talk. I do not know how could I contact you bout the talk so i decided to open this issue :D
At the end of the talk you mention that you can spread "goroutines" across multiple deployments.
I was studing to do that on some services but I didn't found much content on how to comunicate between the pods.
I do know that you can make the pods / services comunicate between them in multiple ways (http, grcp, queues ...). Which way do you do that ? And why ?
Thx for the attention :P