Home / DialogFlow ES / Why I avoid the Dialogflow fulfillment library
DialogFlow ES | Webhooks

Why I avoid the Dialogflow fulfillment library

Website Name Change

I have changed the name of this website from Mining Business Data to BotFlo. I am offering a 70% off discount on my Dialogflow CX course (till April 15th 2021) for people who can help me spread the word about my new website.

In my webhook tutorials, I usually directly construct the JSON and send it back to Dialogflow. Obviously, this has the major benefit of explaining what happens under the hood, as someone pointed out on my YouTube channel:

THANKS THANKS THANKS! For days i have been trying to find a video where people show how to use an external webhook, but from approx. 40 videos i watched, NONE used your solution. They all stick to the Firebase solution. Thanks for your way!

In addition, it is somewhat programming language agnostic and so the tutorial is more useful (if you can understand how the code is constructing the JSON).

But that’s not the only thing.

I usually avoid the Dialogflow fulfillment library entirely.

There are a few reasons for this.

Note: please do not confuse the Dialogflow fulfillment library with the AoG client library (although the code looks very similar). At the moment, the AoG client library is the simplest way to construct JSON responses for Google Assistant apps.

You will find a lot of issues raised on GitHub about how the fulfillment library isn’t up to date with the latest updates in some channel or the other.

It is not up to date

Also, for some context, the authors have already mentioned that the library isn’t maintained and should only be used within the inline editor.

However, they should have gone a step further and also asked people to stop using the inline editor because it is not a very useful tool for serious development work. Otherwise people who do use the inline editor end up going around asking questions like these:

Don’t confuse the NodeJS client library with the Dialogflow fulfillment library
The answer on SO explains the difference

The abstraction is not very helpful

All this might be OK if the abstraction provided by the fulfillment library is extremely good. That isn’t the case at all.

Often, you will have a much clearer understanding of what is going on by inspecting the raw JSON.

I am not sure why this is the case, but I suppose it is because the message object format is too flexible, meaning there are very few rules on what can be combined and what cannot be combined inside the message response JSON.

In any case, handling the pure JSON is often much easier.


If you are building a Dialogflow Messenger bot, I have built a tool which provides a visual editor for the custom payloads. Once you generate the payload JSON as per your requirements, you can just substitute the appropriate variables inside your webhook code.

Similar Posts