CODEWITHSUNDEEP
botframeworkazure-functions
Jasper
Jasper

Reputation: 1837

Structuring a bot deployment with Azure Functions

I've been playing around with the bot framework and have created a new bot using the LUIS engine based on Azure Functions. My main code at the moment is in the CSX file, but I quickly run in to the point where that doesn't feel like it's the right thing to do.

So I was trying to find some best practices on how to best structure these kinds of projects. At the moment I see the following three things that in my opinion need to be separated:

  1. The code that links to the LUIS intent. This should be simple and only contain code to get the right parameters from the intent and entities.
  2. Logic for validation and stuff. For instance: my user enters a period and I want to check whether the entered period is valid (the start date occurs before the end date for instance).
  3. The intent usually is supposed to do something, so we need to have code that triggers this action. The outcome from steps 1 and 2 is used to determine what needs to be done and with which parameters. Seems to make sense to abstract this into another function (per action)??

What I'm looking for is some real world experience on how to set-up an architecture that a) works and b) is usable. And with usable I mean: of course one can create micro services for each little thing, but how to deal with maintenance, source control, updates and all of that stuff. I very much understand that there is probably not one correct answer, but something that points in the right direction would be very helpful to start.

Upvotes: 0

Views: 214

Answers (1)

MaX
MaX

Reputation: 1344

Well it's quite broad question. And I will try to cover as much as I can. So first of all I will highly recommend you going through the C# documentation. There should be fundamentally no difference between CSX and your CS classes. If things feel too hard or you need an IDE experience you can always create a Visual Studio project with all your logic that you will have; and then use the compiled binary assemblies in your function linking the classes.

  • For your LUIS issue, there is already LUISDialog class. It takes care of invoking LUIS, recognizing entities, intents etc. You just have to implement nicely attributed methods. See an example here.
  • For validation and inputs I would recommend looking into FormFlow. It has lot of stuff you are asking for including validation.
  • If you are interested in explicit flow management where you want to take outcome from one step and chain it into next. The SDK already has Dialog Chains.

I think the framework itself provides you with the basic building blocks and then leaves it to your imagination just like any good framework should. The way to organize your code is too subjective. My opinion may not match with what you might have, and there is not fixed patterns like MVC or MVVM here. I usually try to organize my code into 2 parts.

  • Business logic layer. Everything from making calls into your DB, to your validation, to payment gateway, etc. Goes here lives here. This part should be testable, reusable by anyone through classes and interfaces. You can apply all sort of architectures/design patterns here. Idea is this layer is pragmatic interface into your app.
  • Communication layer. This will specifically deal with the Dialogs, FormFlows, Intents etc. and normalize the data to be called into your business logic. This portion will mostly deal with handling user input, and handle all your interaction logic.

Now in case of really huge projects I will probably build nugets out of these layers and reuse it as imported packages in your CSX. In that case the CSX part is really like router, it gives you debugability, local testability via emulator and testcases, and it can be easily deployed by CI just by pushing changes to packages.json.

Upvotes: 1

Related Questions