Running Azure Functions in IIS

gjcampbell — Mon, 20 Jul 2020 02:58:12 +0000

Have you ever wanted to run Azure Functions in IIS? No? "Why would you want to run serverless functions in IIS," you ask.

I won't try to answer why, but I can tell you how. I recently needed to do this and found a void where info should be, so this post is to fill that void.

In Azure, functions are hosted in IIS. (Weird right? Like, I assumed it was something sophisticated and new, not just some duct tapey IIS plugin thing.) I want to find out how much of a function app we can get functioning on-prem with IIS. Yeah, we could just run azure function core tools, but what would we learn from following that well-documented process?

🎪 Basic IIS setup

Let's add a plain, empty site, and bind it to a really good domain.

Since we used a really good domain, we'll need to update our hosts file.

Here's quick test to prove that IIS is set up OK.

Cool so we have a site set up in IIS, and we can deploy a function app to it. Next we'll make a function app, give it a bunch of trigger types, just to see which triggers work in this janky setup.

🧪 A Guinea Pig Function App

Here's a link to the source code.

gjcampbell / iis-azfunc-test

Pretty basic, there's are 4 triggers, and each one just logs. There's a timer, HTTP, queue, and blob trigger. It's logging to a file, so that when it's silently running in IIS, I can see the function app is doing stuff.



[FunctionName(nameof(TestHttp))]
public IActionResult TestHttp(
    [HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)] HttpRequest req)
{
    logger.LogInformation("HttpTrigger ran");
    return new OkObjectResult("Perfect! 🙃");
}

[FunctionName(nameof(TestQueue))]
public void TestQueue([QueueTrigger("iis-q-test")]string item)
    => logger.LogInformation($"QueueTrigger ran value: {item}");

[FunctionName(nameof(TestStorage))]
public void TestStorage([BlobTrigger("iis-blob-test/{name}")]Stream blob, string name)
    => logger.LogInformation($"BlobTrigger ran file name: {name}, size: {blob.Length}");

[FunctionName(nameof(TestTimer))]
public void TestTimer([TimerTrigger("*/20 * * * * *")]TimerInfo timer)
    => logger.LogInformation($"TimerTrigger ran");

I have confirmed that, running from Visual Studio, the function app works as expected. All triggers work and log as configured.

Next from Visual Studio, I'll publish locally to the web site folder. 💥

Yeah, of course that doesn't work. I haven't configured IIS to know what to do with a function app.

🤫 Azure Function IIS Secret Sauce

Check out this cool github page. Azure Functions Host has releases like this one, 3.0.BLAH which we can download and use with IIS.

Download and unzip the Functions.3.0.BLAH.zip somewhere. Next make a web.config file where your function app is published. In the web.config, configure IIS to run aspNetCore module for all paths and verbs, and set the processPath for aspNetCore to the path of Function Host's Microsoft.Azure.WebJobs.Script.WebHost.exe file.

Like this:



<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <remove name="aspNetCore" />
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath="C:\hosting\Functions.3.0.14191\3.0.14191\64bit\Microsoft.Azure.WebJobs.Script.WebHost.exe" hostingModel="InProcess">
      <environmentVariables>
        <environmentVariable name="AzureWebJobsStorage" value="UseDevelopmentStorage=true" />
      </environmentVariables>
    </aspNetCore>
  </system.webServer>
</configuration>

Now what do we get?

Weird, right? It's that default page that you get in azure. What about when we hit the HttpTrigger route?

So HTTP works of course. What about the other triggers? The log says



2020-07-19 21:28:00.0158|INFO|IIS.FuncTest.Tests|TimerTrigger ran

2020-07-19 21:28:20.0162|INFO|IIS.FuncTest.Tests|TimerTrigger ran

2020-07-19 21:28:36.0969|INFO|IIS.FuncTest.Tests|QueueTrigger ran value: adsf

2020-07-19 21:28:40.0181|INFO|IIS.FuncTest.Tests|TimerTrigger ran

2020-07-19 21:28:43.7516|INFO|IIS.FuncTest.Tests|HttpTrigger ran

2020-07-19 21:28:44.1831|INFO|IIS.FuncTest.Tests|BlobTrigger ran file name: 2019_TaxReturn.pdf, size: 637435

2020-07-19 21:29:00.0530|INFO|IIS.FuncTest.Tests|TimerTrigger ran

2020-07-19 21:29:20.0069|INFO|IIS.FuncTest.Tests|TimerTrigger ran

🌻 Summary

Yeah, you can run azure functions in IIS and the vanilla triggers work just fine, and there's really just 2 steps to get it working.

Download the functions runtime
Point to it from your web.config

I'd love to see someone get durable functions working.

I Wrote a Tree Control for Enormous Trees

gjcampbell — Sun, 12 Jan 2020 05:36:41 +0000

A company I was contracting for had a legitimate need for a web-based (angular) tree control that could handle thousands of nodes. I looked around a ton and found nothing really good enough, so I made this one and it handles tens of thousands really well 👌

An Uncommon Problem, I Admit

Most tree controls only need to support a pretty small data set. Like, 100 items max, and it becomes bad UX after that, right? I agree, but after having seen this same problem, huge trees, come up for the third time (three different companies, three different business domains), I wonder if it's not so rare after all.

Yeah, most trees are small, but it happens occasionally, that devs are expected to implement a tree control to handle an amount of data that exposes the tree control's inefficiency.

Smells Like Bad UX, Right?

In most software, a UI featuring an enormous tree of data would be cruel or repellent 🦨 to users. However, trees are ubiquitous, and in the right context, a tree is such a concise data visualization, and what a tree control may lack in elegance is redeemed by its familiarity to users.

It's Challenging Though

Regardless of whether it's right to use a tree for tons of data, it's a tough thing to implement. The file system explorer and your IDE have very well-written tree controls, but try to find a tree implementation as good as those. You'll find innumerable reusable components on github, packed with features, easy to drop in, but absolutely crippled by a large data set. They take forever to load or make interaction laggy and delayed.

I've wondered why efficient tree controls are so hard to find. I assume it's because being super-efficient is rarely necessary for a tree control. And, the time needed to create an efficient reusable tree control is not justifiable, because demand for one is low. 🤷‍♂️

Have I Done it Right?

I think my implementation is correct. It responds quickly to all interactions with a large data set loaded. It handles a huge amount of data, it has all the typical tree features built in, and has no limitations preventing extensibility into more exotic features.

It Works Like This

Virtualization - (not to be confused with virtual dom) To render a very long list of nodes, virtual scrolling is used. In a scrollable container, only the items scrolled into view are visible. Outside of the visible area, is a huge blank space. So, even though the tree may have 10's of thousands of items expanded out, only a handful are rendered in the DOM. Angular has a built in CDK component for virtual scrolling. (It's not great though)
Flattened DOM - Typical tree implementations nest DOM elements. That makes it super easy to implement expand/collapse, indentation, and data binding. However, nesting works against virtualization. Rendering only the visible items and not their parent nodes is complicated and inefficient. So, to accommodate virtualization, all items in the tree are DOM-siblings, regardless of the relationships of the data they represent.
Metadata Preserved - Fine, the DOM is flat in the tree, but the tree's look and feel must remain. Items have to be indented, their children collapsible, etc. So, although the DOM is flat and although it is bound to flattened view of the data, all the necessary relationship data of the hierarchy is preserved, depth, ancestry, etc.

The Short Version

The recipe 🎂 for an efficient tree control supporting tons of data is pretty simple:

Preserve metadata (so that the tree can look right even though flat)
Flatten (so that you can virtual scroll)
Virtual scroll (so that you can handle a huge list)

Thanks

🙏Check out the demo and the source code, and let me know what you think!

DEV Community: gjcampbell