Azure Functions are great. By default, all HTTP functions on Azure have their URLs prefixed with /api. For example, if you have functions named Function1 and Function2, you’d reach them by calling http://my-app.azurewebsites.net/api/Function1 and http://my-app.azurewebsites.net/api/Function2.

Usually, this is fine. But it seems like an arbitrary restriction. What if you’d rather not have it?

Fortunately, there’s a configuration option in your function app’s host.json file to change it. Unfortunately, as I’m writing this, Microsoft’s documentation is incorrect.

It tells you your host.json should look something like this if you want to remove the /api prefix:

{
    "http": {
        "routePrefix": ""
    }
}

This won’t work. If you’re running Visual Studio, it’ll tell you Property name is not allowed by the schema. Instead, the http object must be placed inside of extensions:

{
  "version": "2.0",
  "extensions": {
    "http": {
      "routePrefix": ""
    }
  }
}

Setting routePrefix to an empty string removes /api from the URL. Now, to access Function1, you’d call http://my-app.azurewebsites.net/Function1.

Also note the version property. If you don’t add this, the Azure Functions local simulator will flip out and fall into an infinite loop of scary-looking error messages:

If host.json is blank, the simulator will be fine. But as soon as you add anything else to host.json, you also have to add a version, or the simulator will go crazy.

And that’s it! You now know how to remove /api from your Azure Functions URLs. You can also use a non-blank string to use a prefix other than api. If you’d like your functions URLs prefixed by popcorn or cats, there’s nothing stopping you!

The post How to remove /api from Azure Functions URLs appeared first on Ryan Peden.

Not doing this doesn’t mean you’re a bad developer. It’s entirely possible to use JavaScript effectively without digging in to understand how JS arrays are implemented. But taking a closer look can help you understand performance issues your might run into, so it’s a worthwhile exercise.

How exactly they are implemented depends on the specific JavaScript interpreter or VM you’re using. I’m going to use the V8 JavaScript engine (used by Chrme and Node.js) as an example. Other JavaScript engines, such as Mozilla’s SpiderMonkey and Microsoft’s Chakra will be similar but not identical.

JavaScript Arrays in V8

In V8, if your array only contains integers, it’ll be backed by a C++ array of integers. Typically, the backing array will be bigger than the number of integers it currently contains. If it contains a mixture of integers and floating point values or only floating point values, it’ll be backed by an array of doubles.

If the array contains only objects, or a mixture of numbers and objects, it’ll backed by an array of pointers. Even though JavaScript itself doesn’t have a concept of ‘integer’ or ‘double’ – it just sees them all as ‘number’, V8 keeps track and makes it so arrays are a bit faster and more memory efficient if you only put integers in them.

If you call push() when the backing array is full, it’ll allocate a new, bigger backing array, copy the existing elements over, and then add the new value you pushed. This is similar to the implementation of ArrayList in Java or vector in C++.

All of the above only is only sure to apply if your array is packed, and not sparse – i.e. you don’t have any gaps in the array. If you do something like

let abc = [1,2,3];
abc[100] = 50;

you now have a sparse array. If is not too spare, it’ll still be backed by an array, with empty array indices replaced with a ‘hole’ value. If you look at V8’s C++ array source (linked below), you’ll see calls to element->is_the_hole(i). If an array is very sparse, it’ll no longer be backed by an array in memory. Instead, it will be backed by a dictionary/hashtable, and it’ll take longer to both access elements and iterate through the array.

If you’re interested, you can read through V8’s array implementation in C++ here. You’ll notice that it often checks the following constants:

• PACKED_SMI_ELEMENTS – a packed integer array
• PACKED_DOUBLE_ELEMENTS – a packed double array
• PACKED_ELEMENTS – a packed object array
• HOLEY_SMI_ELEMENTS – a sparse integer array
• HOLEY_DOUBLE_ELEMENTS – a sparse double array
• HOLEY_ELEMENTS – a sparse object array
• DICTIONARY_ELEMENTS – a very sparse array that is backed by a dictionary

And you’ll see that it always tries to do whatever will be fastest for the array it is operating on. Lots of builtin functions like push, pop, shift, unshift, and concat do different things depending on the array’s density and what kind of elements it contains.

Some other things to keep in mind: if you have an array that only contains integers, and you push a floating point number or other type into it, it will be ‘downgraded’ for the rest of its life, even if you purge the non integers from it.

Also keep in mind that none of these implementation details are guaranteed. A naive implementation of JavaScript’s Array object could be backed by a linked list, and it would still work the same way it does now. It would just be slower.

Actually, if you grab an early copy of the Mozilla source code from 20 years ago, you’ll find that arrays were backed by ordinary JS objects without much optimization, just some extra code to handle special cases like the `length` property.

Digging Deeper

If you’re interested in diving even deeper into V8’s internals, I suggest starting by reading through the source files I linked to above. If you’re not used to C++, understanding it will be a bit of a chore at first.

I recommend sticking with it, though. Learning and understanding a new language is always good – and every extra insight you gain into how JavaScript VMs run your code will make you a more effective JavaScript developer.

If you liked this, you might like these other articles I’ve written:
Using Web Components with React in 2019
An Angular Roadmap – The Past, Present, and Future of Angular

The post How do JavaScript arrays work under the hood? appeared first on Ryan Peden.