Triggers are how your Azure Function starts, so it seems the best place for us to start as well. A trigger defines how your function is invoked. There are several kinds of triggers you can employ to run your function when desired. In general, they have three primary types, including HTTP/Webhooks, timers, and data operations.

So for HTTP trigger, your Azure Function fires whenever an HTTP request hits that endpoint.

For a generic webhook trigger, your function fires when a webhook HTTP request, hits that endpoint from any service that supports webhooks, such as Stripe or Twilio.

A GitHub webhook trigger in specific means that your function fires when an event occurs in your GitHub repository, such as create, delete, download, fork, push, pull requests, commit comment or any of the other several dozen GitHub events.

For a timer trigger your function is called at intervals, we'll actually be creating a timer trigger in our exercise.

A queue trigger means your function fires when a new message comes into your Azure queue storage. The message contents are then passed on as input to the function. We will also be doing a queue trigger in our exercise.

For a service bus trigger, your function fires when a new message arrives from a service bus queue or topic. The message contents are then passed in as input to your function.

A BLOB trigger means that your function fires when a new or updated BLOB is detected, and then the BLOB contents are passed to your function as input or an event hub trigger your function fires when any events are delivered to an Azure Event Hub.

To define those triggers and other bindings for your Azure Function, you create a function.json file that creates the configuration metadata for the function itself. Here you can see an example of a function.json file.

You can see within it that a function can only have a single trigger binding. As we'll discuss later, it can have multiple input slash output bindings. All bindings and triggers will have a direction property and note that for triggers, the direction is always in.

Here you can see examples of several common types of trigger bindings used for implementation of those that we just listed. This code would all be found in your function.json file, typically auto generated by Visual Studio, but you do have direct access to edit it when you desire.

So you can see httpTrigger with an authorization level, a timerTrigger with a schedule, a blobTrigger with the file path to the blob, a queueTrigger with the name of the queue, and so on all of the details necessary for your binding to enable itself to be properly connected to whichever resource you are binding to.

The easiest way to create an Azure Function, and to see all of this is using Visual Studio. You just write your functions, starting with the templates provided, and then publish in the usual way to your Azure Cloud. Note that because any Azure Function can have exactly only one trigger as specified, the trigger type you intend to use is what differentiates your Azure Functions when you create them in Visual Studio, so let's take a look at that.