4developers – thoughts after the conference – part 3 (Azure bots + GraphQL)

Do you know what Azure bots are? Or why shall we consider employing GraphQL as another approach to delivering web services? Please take 5 mins and I hope you will know more after this read.


Have you ever found yourself in a situation when you didn’t know how to satisfy several customers with one particular REST query? It may be puzzling sometimes when the first one asks for lightweight API, the second one – wants to consume all information you can give him and third – would like to have something in the middle. What can you do? Should you treat all of them with a voluminous query which will feed them all? Or create separate calls for each of the customers to satisfy them?

GraphQL to the rescue! During the conference, Piotr has demonstrated this clever approach. Roughly speaking it is a query-oriented API which may filter data you need to avoid overwhelming responses for those who doesn’t need such extensive ones. When you want to get some data – you just send a query in POST request and you get data structure you asked for. Isn’t it wonderful? 😉

It surely is not ideal – it has its pros and cons, however, this approach is not mutually exclusive with REST. You can keep both to preserve old REST functionality, and provide additional value to the client. He would be the one to choose what works better for him so this is a win-win, we don’t lose anything here.

It is not so easy to start with that on. NET – there’s not so much coverage in libraries to use that, but there is at least one. If you are interested, I invite you to Piotr’s GitHub where he managed to employ that solution.

Guess what language has the most libs regarding GraphQL? Yes, JavaScript 🙂 This surely would be a good start if you want to play with that.

Azure bots

And the second player – a quick view on Azure bots capabilities from Adam Marczak. This is a framework which lets you build a bot to e.g. provide simple support service for your customers. Look at below diagram. Let’s assume your customer uses Slack, Messenger, Skype or any other instant messaging service to reach you.

You connect the bot to IM of your choice with using Bot Connector. Then you say hi! and employ LUIS (Language Understanding Intelligent Service) to understand human language. (At this point there are only a few languages available besides English, but you can set up Bing translator to help you out with translation to language that LUIS understands). And that’s it! Setup is done.

Now you must teach the LUIS – which is an AI component – how to react to customer’s requests/questions. How to identify their intents and which parts of the content should be treated as an entity of that intent. For example, the question from the customer:

How can I log in to Twitter?

  • Log in is an intent – the customer wants to access something.
  • Twitter is an entity – this is the product he wants to access.

Given that we can now send a response – we know how to log to Twitter so we send Twitter’s login address.

Such systems (AI) works nicely when they have good knowledge base – so you can teach them a bit how to act when the particular intent is requested, but on Azure portal, it is quite straightforward and painless. Under the hood, this service works on Azure functions I wrote about lastly and uses serverless approach. Here is a great video with deeper explanations how this framework works, how to set up your own bot and how it can possibly be used.

Just Cloud awesomeness I’d say 🙂

Thanks for reading!

Somewhat experienced programmer who tries to find intrinsic meaning in each act he does. Increasingly builds his courage to let his life be driven by passion. Currently giving blogging a whirl.