At Cardinal, we develop solutions that are integrated with Office 365/SharePoint Online through Microsoft Flow, Logic Apps, and SharePoint Designer workflows. One of the difficulties in that type of development is the need to deploy code to Azure in order to debug and test any changes. There are methods for stepping through remote code that has been deployed to Azure, but it’s not as easy as debugging local code and certainly not as fast. That’s where ngrok comes in.
ngrok is a reverse proxy that lets you tunnel requests through your firewall to your local machine. They offer both free and paid version, so try out the free version and then buy in when you’re seeing value.
At this point, you could point your SPD Workflow, Microsoft Flow, or Logic App at the ngrok url and it would route directly to your local process. The problem is that whenever you restart ngrok, you’ll get a new URL for the tunnel. When that URL changes, you’ll need to update the caller, which can be kind of a pain. Instead, I like to set up a Azure Function Proxy. You can add proxies.json as a sibling to your host.json file. An example of one of my ngrok proxies looks like this:
I then just point the caller, an SPD workflow in this case, at the function proxy. Whenever I restart ngrok and get a new url, I do need to update the proxies.json file and deploy one time to update the proxy. after that all of my function changes can be executed on localhost.
I haven’t gone to the next step paying for an ngrok plan which would allow me to get the same ngrok url after each restart.
As an added benefit, ngrok gives you a local page on port 4040 which gives you some additional insight.
Gotcha Warning: In my local.settings.json file I define AzureWebJobsStorage and AzureWebJobsDashboard to “UseDevelopmentStorage=true”. If you do the same, you’ll need to ensure you’ve got the Azure Storage Emulator