Stuzo Finds Flaw in Facebook Messenger’s Chat Bot Development

author-photo
Latest Articles

Facebook Messenger Chat Bot

Authored by: Igor Shubovych, Andrew Makarenko

Overview

The Stuzo engineering team discovered an issue in Facebook Messenger’s API. All API developers should prefer using UUIDs instead of integer numbers.

How Approachable is Facebook Messenger’s Simple Bot?

Yesterday, we were debugging the Facebook Messenger chat bot for our page. The bot worked liked a charm for my colleague and me, so we decided to show it to our boss. Surprisingly, it did not work. You know that feeling when you proudly demonstrate your achievement to your manager and it fails. That’s exactly how I felt yesterday.

After our QA engineer tested the chat bot with different Facebook accounts, she found out that it worked for some accounts but did not work for others. After some investigation and googling, we found the cause of issue, and it is hilarious.

Facebook’s API returns an HTTP response, which contains a user identifier, the field called sender, which is the integer identifier of the sender. It is not the same as the Facebook user ID returned by other Facebook API, just some unique identifier of the user. Facebook’s API treated it as a number, so it returned something like this in JSON:

[codesyntax lang=”javascript” tab_width=”4″ strict=”no”]

{
    ...
    “sender”: 12345678,
    ...
}

[/codesyntax]

However, for some users this number was so big that it was bigger than integer limits for JavaScript. So Facebook’s API returned incorrect JSON for some users. Several people were faced with the same situation as we did. There are few related tickets in Facebook’s bug tracker (one, two). Facebook will fix it soon by returning this number as a String. Meanwhile we can use a json-bigint package.

But the problem is bigger.

Overall, this is a human issue, which could be prevented by Continuous Integration with linting of JSON, using for example json-lint, but there is another view to the problem.

It is the middle of 2016, but some programmers still use integers as IDs in a database. If you still use them, you better stop doing that. Seriously. I am not kidding. Do yourself a favor, for your colleagues, your management, your users. Stop using integers.

It is easy to say but not that easy to do. Auto-increment integer IDs are described in all tutorials and books for databases. They are an essential part of database “hello world” examples. So, if you are a technical writer, please do not provide integer ID examples.

Except limit overflow, there is another danger of using integer IDs: it is not easy to build scalable systems with them. Imagine that the database is big, so you split it into a few servers, for example with master-master replication. In this case, different servers can create records with the same IDs. To avoid this, developers often choose to use master-slave replication, which is not that scalable.

Instead of integer IDs, API developers should use UUIDs – universally unique identifiers or hash IDs. Both are proven solutions, which can prevent many issues when designing a database. UUIDs have their own downsides, but those are minor comparing to the benefits they give – the simplicity of development and designing.

Share this story

Latest Articles

Don't Miss These...

Contact Us

Please let us know if you’re interested in our software services and Open Commerce platform, in scheduling an Insights briefing, or establishing a partnership.

    By submitting the form you agree to receive
    future periodic email communication from Stuzo.

    We use cookies

    We use cookies and other tracking technologies to improve your browsing experience on our website, to show you personalized content and targeted ads, to analyze our website traffic, and to understand where our visitors are coming from. By browsing our website, you consent to our use of cookies and other tracking technologies.