Eat.Drink.Bot

[nke_ise]

Nice work.
Apart from a small glitch when it asked me how many people i was asking for, it did quite well (see image).
Question for you:
have you thought of integrating with the Facebook Messenger Send / Receive API? If so , i would love to hear your thoughts.

[timigod]

@codenature

Decouple the bot from the platform. Make the conversation independent of platform. The bot should only take in a message, parse, generate response and send. The bot should not know where the message came from and where the response is going to. It should be stateless (response is generated based solely on the input to the bot

This is already the case. If you want you, can read a tutorial I wrote on exactly how to build a bot like that with Rails or Sails.

I also do not understand what you mean by stateless. This is built as a REST API, yes. But is it really stateless if the conversation is based on answers to previous questions?

@codenature

Then, write minimal codes to expose your bot to the different platforms: web, mobile app, fb, twitter, etc.

But this minimal codes you speak of, for EACH of the DIFFERENT platforms. Isn’t that what I already said I’m against because the gain isn’t that clear or much? How are these minimal codes different from exactly what I don’t want to do?
Where will the minimal codes live? Will they be different apps or just one with plenty if statements?
Also, mobile apps, won’t they require client code too?

Please explain how your suggestion has solved the problem.

[timigod]

Will look into this. Thanks!

[timigod]

That’s exactly what it is. An API with a vanilla JS client built by @FatherMerry. “Utilizing” different platforms is the work I don’t want to do because I don’t see that there’s a benefit.

[codenature]

I read your article, nice work.

To the questions you raised.

@timigod

This is built as a REST API, yes. But is it really stateless if the conversation is based on answers to previous questions?

No Sir. REST != stateless. If your current deployment is anything similar to the tutorial. We can assume that the singleton WitExtension is your ‘bot’. Your current implementation simply tied a complex knot with the WitExtension, ChatController, WitClient and Model objects. For instance,

def message
    param! :message, String, required: true
    param! :uid, String, required: true
    @conversation = Conversation.find_by_uid(params[:uid]) # you retrieved the current conversation from the db
    WitExtension.instance.set_conversation(@conversation) # set the conversation on the Singleton
    @message = @conversation.messages.create(
        body: message,
        kind: "incoming"
    ) # you then created a new message
    WitExtension.instance.client.run_actions(@conversation.uid, params[:message], @conversation.context) # then you stretched deep inside your singleton to extract the client. 
    puts "SENDING TO WIT #{params[:message]}"
  end

And, things like this within the WitExtension.
@conversation.update(context: new_context)

In my opinion, these complexities simply make the bot (WitExtension) to have too much knowledge of not only the model but also the controller and vice versa. I am curious about how you will write test for this implementation.

@timigod

But is it really stateless if the conversation is based on answers to previous questions?

It could be. Just need to ensure that the bot doesn’t retain or manage any data require to generate response between invocations.

@timigod

Then, write minimal codes to expose your bot to the different platforms: web, mobile app, fb, twitter, etc.

You are the best judge of this. But for me, I think the benefit of running this bot on multiple platforms simply outweigh the cost of writing the trivial codes to make it happen (especially in this age of react js|native).

I do hope you realise that my input was made in good faith (Apology for the code review). I wish you the very best.

[timigod]

@codenature

No Sir. REST != stateless.

This is exactly my point. That it’s REST doesn’t mean it is stateless. A conversion that is meant to respond based on previous answers isn’t stateless by definition.

@codenature

It should be stateless (response is generated based solely on the input to the bot. You can easily achieve that by sending back the entire message tree to the bot to get a new response.)

Sending back the entire message tree to get a new response is as inefficient as it gets. That’s delegating storage of the entire conversation to the client and then making the server go through the whole tree every time it gets a message to respond. It makes way more sense to save state server-side.

@codenature

It could be. Just need to ensure that the bot doesn’t retain or manage any data require to generate response between invocations.

It is a conversation that responds based on previous answers. It should retain data, that is how conversations work. Context is important.

@codenature

You are the best judge of this. But for me, I think the benefit of running this bot on multiple platforms simply outweigh the cost of writing the trivial codes to make it happen (especially in this age of react js|native).

If you really think so, write the code for all the platforms you want then I’ll give you the API docs. It’s pretty simple. Just 3 endpoints.

Like you said, it’s trivial codes, so as long as @Nosaaaa doesn’t have a problem with it, help yourself.

Lastly,

@codenature

the benefit of running this bot on multiple platforms

None of these benefits have been mentioned. If indeed there are benefits, they should have been mentioned by now.

[87_chuks]

@timigod

None of these benefits have been mentioned

If you’re interested in reaching more people and if you’re interested in serving them more conveniently.

Am chatting up my wife on Messenger and need to book dinner for the both of us, it would be more convenient shooting your bot a message on FB than trying to remember if it’s bot.eatdrinklagos.com or boteatdrinklagos.com

[Nosaaaa]

@87_chuks

If you’re interested in reaching more people and if you’re interested in serving them more conveniently.

Am chatting up my wife on Messenger and need to book dinner for the both of us, it would be more convenient shooting your bot a message on FB than trying to remember if it’s bot.eatdrinklagos.com or boteatdrinklagos.com

While it sounds more convenient, the assertion is not backed by the nature of our audience.

[87_chuks]

Okay, so a chat bot on a chat messenger won’t work for your audience? Perhaps there’s a rule against using Eat.Drink.Lagos outside Eat.Drink.Lagos.

Did i mention; decent effort in between!

[Nosaaaa]

@87_chuks

Okay, so a chat bot on a chat messenger won’t work for your audience? Perhaps there’s a rule against using Eat.Drink.Lagos outside Eat.Drink.Lagos.

I think you’re misunderstanding me. Does it make any sense to have chat bot on Facebook when Facebook is the weakest of the platforms we’re present on?

Twitter would probably make more sense as far as a social media bot goes, but there’s also a large section of our older audience that aren’t present on twitter, or any social media.

The bot, as it is right now, is the middle ground we found.

[87_chuks]

Am not a big Eat.drink.Lagos reader but if there was a recommender bot that connected the dots for me according to my preferences i’d defly stay connected, as the need arises.

Any reason why you should see this as a solution for just your present audience set? You might be breaking grounds with new pips even on your weakest platform.

[Nosaaaa]

@87_chuks

Any reason why you should see this as a solution for just your present audience set? You might be breaking grounds with new pips even on your weakest platform.

The initial goal isn’t to reach new people. It’s to reach an already curated audience. When we successfully do that, we can venture beyond. Launching on a platform we don’t have an established presence on is a bit too ambitious for us.