The 6 ways of returning data from an Azure Function

Why have one if you can have many? Well, beats me, but I thought I’d collect them here so I have my personal reference. Disclaimer: This is only for JavaScript based functions (most of the examples on the MS pages are C#).

So, most of them have to do with the file function.json  file:

    "bindings": [{
        "type": "httpTrigger",
        "name": "req",
        "and": "so on ..."
    }, {
        "type": "http",
        "name": "thisIsAnOutputBinding",
        "direction": "out"
    }, {
        "type": "someOtherType",
        "name": "anotherBinding",
        "direction": "out"

More precisely, with the “out” type binding that is defined in the 2nd “bindings” object. The “out” binding has a “name” property, which is basically relevant for all of the methods.

!!!!! WARNING !!!!! – It seems the name of the binding property must be camelCase. At least I consistently get “invalid binding” errors when I use snake_case

Method 1 – context property

The context object has one property per defined “out” binding. So if our property is named “thisIsAnOutputBinding”, our result property is context.thisIsAnOutputBinding , or as MicroSoft puts it:

Outputs (bindings of direction === “out” ) can be written to by a function in a number of ways. In all cases, the name property of the binding as defined in function.json corresponds to the name of the object member written to in your function.

Simply put, you just assign the value to a context  member and you’re done:

module.exports = function(context, req) {
    context.thisIsAnOutputBinding = {
        "my": "return value",
        "in this case": "an object"
    // contect.done() is only needed for synchronous functions context.done();

Source here.

Method 2 – return an object (async functions only)

With the bindings given above, you can assign the values to the context property, but you can also return an object whose keys correspond to the binding names:

module.exports = async function(context) {
  return { thisIsAnOutputBinding: 42, anotherBinding: 43 };
  // of course, instead of 42/43 you can put any js object here.


Source here.

Method 3 – using context.bindings

This is basically a variant of method 1. Why does it exist? No one knows. Apparently the context object has a .bindings  property, which in turn again has properties which name-match the defined out bindings. So this is another possibility, and I think the return  is unnecessary:

module.exports = async function(context) {
  let retMsg = "Hello, world!";
  context.bindings.thisIsAnOutputBinding = {
    body: retMsg
  context.bindings.anotherBinding = retMsg;

Source here.

Method 4 – using context.done()

If you’re using a sync method, you can’t return an object, but you can call context.done(err, obj) .

module.exports = async function(context) {
  context.done(null, {
    thisIsAnOutputBinding: { text: "hello there, world", anotherBinding: 42 }

Source here.

Method 5 – just return it already (only async functions)

Probably someone said “Well, if I only have one output binding, why should I explicitly address it?”, which is a valid thought. So another way to return data was invented.

For this the configuration in function.json looks a bit different:

  "bindings": [
    { "type": "someType", name: "req", direction: "in" },
    { "type": "someOutType", direction: "out", name: "$return" }

You have to set exactly one “out” type binding, and the name must be “$return”. Then you can do this:

module.exports = async function(context, req) {
  return "woohooo!!";

Source here.

Methods 6 – special for http outputs

You thought we were done? Noooooo. For http methods, you can diretly return the body object which is then used to create the body

// actually NO IDEA if this works sync, async or both
// my guess is: sync, because "context.done() is implicitly called"
module.exports = async function(context, req) {
  rv = { body: "<html/>", status: 201 };

Source here.


Let’s just say it’s a mess, and too many ways ruin the map.

It works though.

Desktop shit

Win10 & Veracrypt & systemd-boot

There are some things seemingly nobody does. For example, …

  • double-booting Win10 and Linux
  • on an UEFI System
  • while the Win10 Partition is encrypted using VeraCrypt.

Yes, it’s a complex scenario, but since MS in all of his (money-grabbing) wisdom does not include BitLocker in Win10 Home, this is a necessary precaution. I’ll not go over the installation of both systems (pretty straightforward, and Arch Linux has – as always – a nice Wiki entry about it).

Unfortunately, Win10 likes to break its own boot manager on updates, which is very scary (“Your Windows partition is damaged”), and super annoying, but I think I got the solution now.

So, the Linux-based (of course) solution for Windows 10 and VeraCrypt is:

# esp partition - /loader/entries/winvera.conf
title Windows 10 VeraCrypt
efi /EFI/VeraCrypt/DcsBoot.efi

This is in fact all you need to do. Now, if Windows fucks up its own boot loader, it seems systemd-boot just ignores everything, loads the correct VeraCrypt bootloader (as it is supposed to be), and all is well.

It can happen though that Windows places its own boot manager back in front of systemd-boot again, so it’s used as the default one. Then use one of the methods described here, and you should be fine. (This did not happen to me, it always used the correct boot manager but fucked up Windows boot)