[Discussion] Proposed API changes for next version

[theycallmeswift]

Hey, Dialogflow team & community --

I recently built a production Twilio chatbot using Dialogflow and I wanted to share some feedback/ideas based on my experience. I'd like to use this thread as a place to discuss these ideas and will make issues/pull requests for the ones that have traction. Some of these may be service level API level changes, so if you think there's a better place to share them please let me know.

Excited to hear your thoughts and questions!

1. Implement a real router

Problem:

Right now you only have two major routing options - a single function or a Map between intent names and functions. The single function works well for simple apps, but doesn't scale well when your application becomes more complex. The Map scales a bit better, especially when you have discrete logic for each intent, but it breaks easily because it's based solely on an exact match with the name of the intent. Things get more complicated when you have several intents that all represent a single action, but have slightly different names (Ex. "Welcome Intent (Logged In)" & "Welcome Intent (Logged Out)").

Proposed Solution:

• Implement an actual router class that can take in more complex inputs like regular expressions. (Ex. route.intent('^Welcome Intent - (.*)', handleWelcomeIntent))
• Allow routing on more than just the intent name (action, contexts, etc). (Ex. route.action('welcome-action', handleWelcomeIntent) or route.event('welcome', handleWelcomeIntent))

2. Add Middleware Support

Problem:

Some of my intents would benefit from being able to run a series of functions to manipulate the agent before it is passed to the ultimate handler. Use cases include authentication, calling other APIs/services, etc. Right now the only way to do this is to write increasingly complex handler functions.

Proposed Solution:

• Implement agent-wide middleware support that runs every function in the chain before each request is handled. (Ex. app.use( (agent, next) => { /* Login Logic */ })).
• Implement route specific middleware that is only run of the route is called:
  (Ex. route.action('welcome-action', [middelware1, middleware2], handleWelcomeIntent))

3. Update the outgoing message logic

Problem:

The way that messages are sent is not intuitive. This libray only allows a single predefined response, but the dialogflow GUI will randomly select one from a list. This library also doesn't allow sending mutliple messages, which is a common pattern. Futher, the default console messages are completely ignored and would be a great default set of responses to fall back on.

Proposed Solution:

• Add messages that aren't tagged to a specific platform to the "DEFAULT" response stream. Right now the agent errors if there is not a platform specific response defined. Really this error should only occur if there is no platform specific response and there is also no default response defined.
• Allow sending multiple messages. Right now you can only send a single responses, but multiple agent.add(msg) calls should send multiple messages.
• Randomly select a response when an array of messages is passed in.
  (Ex. agent.say([msg1, msg2, msg3]) should randomly send one of those messages, which is what the Dialogflow GUI does).
• Default to the messages in consoleMessages if no new response was added. If I never call agent.add, then why shouldn't the bot respond the way it intended to?

[mattcarrollcode]

1 & 2 are good feedback and we'll consider them for future releases. for #3 you should be able to send multiple responses with multiple agent.add calls. Can you open a new issue detailing your situation where multiple agent.add calls doesn't actually send multiple messages? Please include your code, and what platform your testing on when you do.

[r-nasiri]

I've submitted PR #172 for middleware support(item 2). It supports multiple middlewares that will run one after each other and you can implement your intent specific logic inside the middleware.