I want to create a bot that multiple people could add to their pages. I like your idea of returning a channel of Callbacks, but it might need pulling apart once I add multiple pages.
Sorry if this feels a bit stream-of-consciousness: I'm mostly just trying to organise my thoughts (this is my first Go project, but I've written messenger bots in other languages).
I think that it might be enough to copy Entry.PageID into the Callback struct, and then make the Callback channel consumer maintain a mapping from PageID to BotAPI. This feels ugly though.
Alternatively we could remove BotAPI.Token, and replace it with a mapping from PageID to Page (might want renaming) which would look something like:
which would return true if it called AddPage(), to make the BotAPI retry the Entry.
SetWebhook() could then lose the <-chan Callback part of its return value.
In a world where you want to add a page to a live load-balanced website, you would need to:
Write the PageID and Token to a Database somewhere.
Tell Facebook to subscribe to the webhooks for that page.
When webhooks start coming in, make your HandleUnknownPage() callback pick the token out of your Database and call AddPage().
Of course, if you're load-balancing your webhook requests onto random servers then they won't be showing up in a stream anymore, so the <-chan Callback interface stops making sense, and you might as well just use callback functions 😞 . Also, if your HandleUnknownPage() callback is expensive then you might end up in trouble if you accidentally subscribe to webhooks without writing the Token to the DB.
Is this an approach that's worth pursuing, or should I just look for a callback-function-based messenger lib that's already capable of handling multiple pages?
I want to create a bot that multiple people could add to their pages. I like your idea of returning a channel of Callbacks, but it might need pulling apart once I add multiple pages.
Sorry if this feels a bit stream-of-consciousness: I'm mostly just trying to organise my thoughts (this is my first Go project, but I've written messenger bots in other languages).
I think that it might be enough to copy Entry.PageID into the Callback struct, and then make the Callback channel consumer maintain a mapping from PageID to BotAPI. This feels ugly though.
Alternatively we could remove BotAPI.Token, and replace it with a mapping from
PageIDtoPage(might want renaming) which would look something like:A bunch of methods would move from being on BotAPI to being on Page.
We could then create a function like:
which adds a
Pageto theBotAPIand then returns it along with channel of Callbacks.Any
Entrythat doesn't belong to aPagecould then be sent to a callback function:which would return true if it called AddPage(), to make the BotAPI retry the Entry.
SetWebhook()could then lose the<-chan Callbackpart of its return value.In a world where you want to add a page to a live load-balanced website, you would need to:
HandleUnknownPage()callback pick the token out of your Database and callAddPage().Of course, if you're load-balancing your webhook requests onto random servers then they won't be showing up in a stream anymore, so the
<-chan Callbackinterface stops making sense, and you might as well just use callback functions 😞 . Also, if yourHandleUnknownPage()callback is expensive then you might end up in trouble if you accidentally subscribe to webhooks without writing the Token to the DB.Is this an approach that's worth pursuing, or should I just look for a callback-function-based messenger lib that's already capable of handling multiple pages?