If you followed Microsoft’s coverage from the Build 2018 conference, you may have been as excited as we were about the new Visual Studio Live Share feature that allows instant, remote, peer-to-peer collaboration between Visual Studio users, no matter where they are. One developer could be sitting in a coffee shop and another on a plane with in-flight WiFi, and yet both can collaborate directly on code.
The “networking magic” that enables the Visual Studio team to offer this feature is the Azure Relay, which is a part of the messaging services family along with Azure Service Bus, Azure Event Hubs, and Azure Event Grid. The Relay is, indeed, the oldest of all Azure services, with the earliest public incubation having started exactly 12 years ago today, and it was amongst the handful of original services that launched with the Azure platform in January 2010.
In the meantime, the Relay has learned to speak a fully documented open protocol that can work with any WebSocket client stack, and allows any such client to become a listener for inbound connections from other clients, without needing inbound firewall rules, public IP addresses, or DNS registrations. Since all inbound communication terminates inside the application layer instead of far down at the network link level, the Relay is also an all around more secure solution for reaching into individual apps than using virtual private network (VPN) technology.
In time for the Build 2018 conference, the Relay learned a brand-new trick that you may have missed learning about amidst the torrent of other Azure news, so we’re telling you about it again today: The Relay now also supports relayed HTTP requests.
This feature is very interesting for applications or application components that run inside of containers and where it's difficult to provide a public endpoint, and is especially well-suited for implementing Webhooks that can be integrated with Azure Event Grid.
The Relay is commonly used in scenarios where applications or devices must be reached behind firewalls. Typical application scenarios include the integration of cloud-based SaaS applications with points of sale or service (shops, coffee bars, restaurants, tanning salons, gyms, repair shops) or with professional services offices (tax advisors, law offices, medical clinics). Furthermore, the Relay is increasingly popular with corporate IT departments who use relay based communication paths instead of complex VPN setups. We will have more news regarding such scenarios in the near future.
The new HTTP support lets you can create and host a publicly reachable HTTP(-S) listener anywhere, even on your phone or any other device, and leave it to the Azure Relay service to provide a resolvable DNS name, a TLS server certificate, and a publicly accessible IP address. All your application needs is outbound Websocket connectivity to the Azure Relay over the common HTTPS port 443.
For illustration, let’s take a brief look at a simple Node.js example. First, here’s a minimal local HTTP listener built with Node.js “out of the box”:
var http = require('http');
var port = process.env.PORT || 1337;
http.createServer(function (req, res) {
res.writeHead(200, { 'Content-Type': 'text/plain' });
res.end('Hello Worldn');
}).listen(port);
This is the equivalent Node.js application using the Azure Relay:
var http = require('hyco-https');
var uri = http.createRelayListenUri("cvbuild.servicebus.windows.net", "app");
var server = http.createRelayedServer({
server: uri,
token: () => http.createRelayToken(uri, "listen", "{…key…}")
},
function (req, res) {
res.writeHead(200, { 'Content-Type': 'text/plain' });
res.end('Hello Worldn');
}).listen();
The key changes are that the Relay application uses the ‘hyco-https’ module instead of Node.js’ built-in ‘http’ module, and that the server is created using the ‘createRelayedServer’ method supplying the endpoint and security token information for connecting to the Relay. Most important: The Node.js HTTP handler code is completely identical.
For .NET Standard, we have extended the existing Relay API in the latest preview of the Microsoft.Azure.Relay NuGet package to also support handling HTTP requests. You create a HybridConnectionListener as you do for Websocket connections, and then just add a RequestHandler callback.
var listener = new HybridConnectionListener(uri, tokenProvider);
listener.RequestHandler = (context) =>
{
context.Response.StatusCode = HttpStatusCode.OK;
context.Response.StatusDescription = "OK";
using (var sw = new StreamWriter(context.Response.OutputStream))
{
sw.WriteLine("hello!");
}
context.Response.Close();
};
If you want to have existing ASP.NET Core services listen for requests on the Relay, you use the new Microsoft.Azure.Relay.AspNetCore NuGet package that was just released and that allows hosting existing ASP.NET Core apps behind the Relay by adding the “UseAzureRelay()” extension to the web host builder and configuring the connection string of a Hybrid Connection shared access rule (see readme, more samples).
public static IWebHost BuildWebHost(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.UseStartup()
.UseAzureRelay(options =>
{
options.UrlPrefixes.Add(connectionString);
})
.Build();
The HTTP feature is now in preview in production, meaning you can use it alongside the existing Relay features, complete with support and SLA. Because it’s in preview and not yet entirely in its final shape, we might still make substantial changes to the HTTP-related wire protocol.
Since the Relay isn’t a regular reverse proxy, there are some lower level HTTP details that the Relay overrides and that we will eventually try to align. An exemplary known issue of that sort is that the Relay will always transform HTTP responses into using chunked transfer encoding; while that is might be fairly annoying for protocol purists, it doesn’t have material impact on most application-level use cases.
To get started, check out the tutorials for C# or Node.js and then let us know via the feedback option below the tutorials whether you like the new HTTP feature.