Create: Serverless 2020

UPDATE

Due to some unfortunate changes in decision making, I was unable to proceed with talking at Create: Serverless. I will likely post the remainder of content here, at dev.to, and on twitch for more indepth talk/walk throughs.

Best Practices

I've been asked by the Azure Functions team to do a segment on Function Apps and some best practices, which is turning out to be a great task to learn more about functions done in other languages and a trip down memory lane. It's extremely exciting to asked again to cover functions, as there was some discussion for a similar segment for BUILD 2020 that didn't materialize; getting to talk about what that I've learned both professionally and personally to help ease some of the growing pains and share knowledge will be very rewarding (and hopefully valuable for the community).

To share a little bit about what that will be discussed, at least as of writing this, I'll be going over more beginner to intermediate level things with a sprinkling of advanced/niche things for development, deployment, and troubleshooting. One thing that's probably not going to make into the event is the concept of OutOfProc execution the ordering of parameters. When using an OutOfProc language like Node.js or python, the order of the parameters passed to the function definition are influenced by the function.json, but the name property for the binding is irrelevant. In the below example I have both the function.json and the function definition, but notice that the second parameter that is the httpTrigger definition name doesn't match the name of the second parameter, this behaviour is common for nearly all input bindings.

function.json
{
  "bindings": [
    {
      "type": "httpTrigger",
      "direction": "in",
      "name": "req"
    },
    {
      "type": "http",
      "direction": "out",
      "name": "res"
    }
  ]
}

While the input binding name is req, order does matter for multiple inputs, you can make the function signature look like the following and still get the input value from the execution:

async function (ctx, request){
  // fn logic
}

Another interesting one is the concept of implicit vs explicit returns for HTTP Trigger functions. When designing and implementing a function, you have the option of picking whether you want to directly return or implicitly return by setting the output binding's name to $return

function.json
{
  "bindings": [
    ...
    {
      "type": "http",
      "direction": "out",
      "name": "$return"
    }
  ]
}

async function (ctx, request){
  // fn logic

  return someValue
}

The alternative option for returning, which is the default init for a new node HTTP Trigger in vscode and in the example docs, is more useful if you want control the values of headers, beyond what is configurable in the host.json and set the status code beyond 200/204 for return values.

function.json
{
  "bindings": [
    ...
    {
      "type": "http",
      "direction": "out",
      "name": "res"
    }
  ]
}

async function (ctx, request){
  // fn logic

  ctx.res = {
    body: 'fancy response'
    status: 201,
    headers: { someHeader: "someValue" }
  }
}

I'll have more posts up like this in the future to go over some of the items I'll cover in my segment, but also to help me get the components ironed out on my end.