One of the themes of Developer Week is “it takes a village”, and observability is one area where that is especially true. Cloudflare Workers lets you quickly write code that is infinitely scalable — no availability regions, no scaling policies. Your code runs in every one of our data centers by default: region Earth, as we like to say. While fast time to market and effortless scale are amazing benefits, seasoned developers know that as soon as your code is in the wild… stuff happens, and you need the tools in place to investigate, diagnose, fix and monitor those issues.

Today we’re delighted to add to our existing analytics partners. We’re announcing new partnerships with six observability-focused companies that are deeply integrated into the Cloudflare Workers ecosystem. We’re confident these partnerships will provide immediate value in building the operational muscle to maintain and make your next generation of applications fast, secure and bullet-proof in production.

console.log(`Got request. Extracted name=${name}. Saving…`);

Cloudflare wrangler gives you the ability to generate, configure, build, preview and publish your projects, from the comfort of your dev environment. Writing code in your favorite IDE with a fully-fledged CLI tool that also allows you to simulate how your code will run on the edge is a delightful developer experience and one I personally love.

If you’re like me, you’ll start out your app with console.log statements. wrangler dev and wrangler tail both make it incredibly easy to get visibility into your code during dev and test, but for robust applications, you need more — much more. Things like correlating client and server side event data, seeing context around issues, version awareness and data visualization are what allows DevOps teams to create truly robust applications and make customers happy. The great news is — it’s easy to go from console.log to a code or systems monitoring solution with our partners Sentry and New Relic.

Sentry enables monitoring application code health. From error tracking to performance monitoring, developers can see issues that really matter, solve them more quickly, and learn continuously about their applications — from frontend to backend.

Toucan-js, courtesy of Cloudflare’s very own Robert Cepa, is a reliable Sentry client for Cloudflare Workers and it’s an open-source npm module. It makes it easy to convert basic logging into full application monitoring. A simple npm install toucan-js and a couple of lines of boilerplate setup allow you convert those console.logs into a streaming source of client-side events that will be rendered for analysis in Sentry. Additionally, the distributed nature of serverless means developers need to think about where and how they can manage state. Toucan-js abstracts that away and allows simple log statements like:

sentry.addBreadcrumb({
    message: "Got request. Extracted name=${name}. Saving…",
    category: "log"
});

to be visualized in Sentry as a user journey with filters, times, versioning and more, allowing you to understand what events led to the errors.

New Relic is a popular observability platform, particularly with Enterprises offering a Telemetry Data Platform, Full-Stack observability and Applied Intelligence. While there isn't (yet!) a specific npm package for NewRelic and Cloudflare Workers, the combination of NewRelic’s https log endpoint and Cloudflare Workers event.waitUntil() means you can very easily instrument your application with NewRelic, without blocking the request and thus not impacting performance.

let url = "https://log-api.newrelic.com/log/v1";
let init = {
	method: "POST", 
	headers: {"content-type":"application/json"}, 
	body: JSON.stringify(payload)
};
event.waitUntil(fetch(url, init));

Like Sentry, those logs and events are then available for analysis in the NewRelicOne platform. Cloudflare uses both Sentry and New Relic for exactly the reasons outlined above, and I’m delighted to welcome them to our Developer Ecosystem as Observability Partners.

New Relic One | New Relic

Monitoring your Cloudflare Workers serverless environment with New Relic lets you deliver serverless apps with confidence by rapidly identifying when something goes wrong and quickly pinpointing the problem—without wading through millions of invocation logs. Monitor, visualize, troubleshoot, and alert on all your Workers apps in a single experience.-- Raj Ramanujam, Vice President, Alliances and Channels, New Relic.

With Cloudflare Workers and Sentry, software teams immediately have the tools and information to solve issues and learn continuously about their code health instead of worrying about systems and resources. We’re thrilled to partner with Cloudflare on building technologies that make it easy for developers to deploy with confidence.-- Elain Szu, Vice President of Marketing, Sentry.

Developers are not the only part of an organization that need to observe all aspects of their applications in production. As organizations grow and the sophistication of their infrastructure monitoring and security systems grow, they typically implement observability platforms, which provide overall visibility into the entire infrastructure and the ability to alert on anomalies — not just individual applications, appliances, hardware or network. To achieve that goal, observability platforms must ingest as much data as possible. Cloudflare already partners with Datadog, Sumo Logic and Splunk — this allows security and operations teams to ingest HTTP logs from the network edge along with origin logs and many other sources of data.

Since that announcement, specific Cloudflare Workers fields such as WorkerCPUTime, WorkerStatus, WorkerSubrequest, and WorkerSubrequestCount have been added to offer out-of-the-box visibility to Cloudflare Workers execution. Of course, since the value of observability platforms is about whole-of-infrastructure visibility, ideally we want not just execution logs, but the application logs from our systems, similar to the examples in the section above.

Fortunately, our partners all offer simple HTTP interfaces into their ingestion engines. Check out Datadog’s HTTP API, Splunk’s REST API and SumoLogic’s HTTP Logs and Metric Source for step-by-step instructions on how to easily ingest your Cloudflare Workers logs. Besides getting on your CISO’s good side, if your organization has a Detection and Response team, they’ll be able to help you ensure your Cloudflare Workers application is integrated and monitored as a first-class citizen in your organization's security apparatus. For example, the screenshot below shows Datadog surfacing a security signal detecting malicious activity in Cloudflare HTTP logs based on threat intel feeds.

Maintaining a strong security posture means ensuring every part of your toolchain is being monitored - from the datacenter/VPC, to your edge network, all the way to your end users. With Datadog’s partnership with Cloudflare, you get edge computing logs alongside the rest of your application stack’s telemetry - giving you an end to end view of your application’s health, performance and security.- Michael Gerstenhaber, Sr. Director, Datadog.

Teams using Cloudflare Workers with Splunk Observability get full-stack visibility and contextualized insights from metrics, traces and logs across all of their infrastructure, applications and user transactions in real-time and at any scale. With Splunk Observability, IT and DevOps teams now have a seamless and analytics-powered workflow across monitoring, troubleshooting, incident response and optimization. We're excited to partner with Cloudflare to help developers and operations teams slice through the complexity of modern applications and ship code more quickly and reliably.- Jeff Lo, Director of Product Marketing, Splunk

Reduce downtime and solve customer-impacting issues faster with an integrated observability platform for all of your Cloudflare data, including its Workers serverless platform. By using Cloudflare Workers with Sumo Logic, customers can seamlessly correlate system issues measured by performance monitoring, gain deep visibility provided by logging, and monitor user experience provided by tracing and transaction analytics.- Abelardo Gonzalez, Director of Product Marketing at Sumo Logic

Honeycomb.io is an observability platform that gives you high level data regarding how your services are performing, combined with the ability to drill down all the way to the individual user level to troubleshoot issues without having to hop across different data types to piece the data together. Traditionally, when debugging production incidents with dashboards and metrics, it is difficult to drill down beyond aggregate measures. For example, a graph with error rates can’t tell you which exact customers are experiencing the most errors. Logs show you the raw error data, but it's hard to see the big picture unless you know exactly where to look.

Honeycomb’s event-based model for application telemetry and powerful query engine make it possible to slice your data across billions of rows and thousands of fields to find hidden patterns. The BubbleUp feature also helps you automatically detect the differences between “good” sets and “bad” sets of events. The ability to quickly get results means teams can resolve incidents faster and figure out where to make system optimizations.

The Honeycomb beta npm module for Cloudflare Workers observability is unique, in that it has first-class knowledge of the concept of sub-requests that are a core part of many Worker applications, and this is surfaced directly in the platform. We can’t wait to see the GA version and more innovation around observability for Cloudflare Workers.

Honeycomb is excited to partner with Cloudflare as they build an ecosystem of tools that support the full lifecycle of delivering successful apps. Writing and deploying code is only part of the equation. Understanding how that code performs and behaves when it is in the hands of users also determines success. Cloudflare and Honeycomb together are shining the light of observability all the way to the edge, which helps technical teams build and operate better apps.- Charity Majors, Honeycomb CTO & cofounder.

Developers love writing code on Cloudflare Workers. The speed, scale, and developer tooling all combine to make it a delightful experience. Our observability partner announcements today extend that experience from development to operations. Getting real-time, contextual insights into what your code is doing, how it’s performing and any errors it’s generating is at the core of shipping the next generation of transformative apps. Our serverless platform takes care of getting your code right next to your users, and our observability partners make sure that that code does exactly what you designed it to do.

Today, we are launching our WAN and SD-WAN partnerships with VMware, Aruba and Infovista. We are also adding Digital Realty, CoreSite, EdgeConneX, 365 Data Centers, BBIX, Teraco and Netrality Data Centers to our existing Network Interconnect partners Equinix ECX, Megaport, PacketFabric, PCCW ConsoleConnect and Zayo. Cloudflare’s Network On-ramp partnerships now span 15 leading connectivity providers in 70 unique locations, making it easy for our customers to get their traffic onto Cloudflare in a secure and performant way, wherever they are.

With Magic WAN, customers can securely connect data centers, offices, devices and cloud properties to Cloudflare’s network and configure routing policies to get the bits where they need to go, all within one SaaS solution: no more MPLS expense or lead times and no more performance penalties from traffic trombones. Many organizations use physical or virtual SD-WAN appliances today to route or tunnel traffic between offices, data centers, and public clouds. Starting today, these customers can leverage their existing infrastructure investments — physical or virtual in the cloud — to connect traffic to Magic WAN with a few simple commands.

Consider the sample setup below. Magic WAN + Network Onramp Partners allows you to connect on-premise and cloud VPCs in RFC1918 subnets using both physical and virtual appliances, with Magic WAN providing accelerated and secure connectivity. Additionally, Magic Firewall allows you to configure and enforce firewall rules at edge and consistently across all traffic that flows through Magic WAN. Cloudflare’s broad network reach in 200+ cities also means the nearest data center is always close by.

3 private networks, using a mixture of a partner hardware appliance, a partner virtual AMI, and a generic Linux router connected to Cloudflare Magic WAN via the nearest Cloudflare data center.

While simple setup and compatibility are great, our shared roadmap with our partners is much more ambitious. Today, these connections are made over Anycast GRE, and we will be announcing IPSec support soon, allowing customers multiple connectivity methods.  

In future releases, on-ramp partner devices will only require authorization credentials to prove they are part of a customer Magic WAN network, and will then be able to call out to the Magic WAN management API and self-configure — truly realizing the plug’n’play vision of cloud networking. Additionally, Magic WAN customers will be able to benefit from layering Cloudflare's Zero Trust security for application access and Internet browsing that unites Zero Trust network access (ZTNA), Secure Web Gateway (SWG), Remote Browser Isolation (RBI), DNS security, L4 firewall, and other once-distinct point products into one seamless platform.

“VMware SD-WAN virtualizes the WAN to decouple network software services from the underlying hardware—providing agility and performance for all enterprises and is a foundational component of the VMware Secure Access Service Edge (SASE) platform. VMware and Cloudflare share a vision to provide customers a cost-effective, turnkey and more secure Global WAN.”- Mark Vondemkamp, vice president products, SD-WAN and SASE business, VMware.

“Aruba, a Hewlett Packard Enterprise company, is pleased to collaborate with Cloudflare to develop solutions that will enable our customers to easily deploy the Aruba EdgeConnect SD-WAN platform, acquired with Silver Peak, as the enterprise connectivity onramp to the Cloudflare Magic WAN and Magic Firewall. This new solution builds on the Aruba EdgeConnect platform’s best-in-class integration with leading cloud connectivity and security services, and will enable customers to utilize Cloudfare’s Global Edge Network to protect and accelerate cloud workloads.”- Fraser Street, Head of WAN technical alliances for Aruba.

Tunneling traffic to the nearest Cloudflare data center (which since we’re in over 200 cities, is always close by) is at the heart of Cloudflare Magic WAN. We use standard Internet protocols like GRE and IPSec (coming soon) to securely deliver traffic between our network and our customers’ infrastructure. While protocol-level security is great, anytime you have Internet-facing infrastructure, you open up an attack surface to misconfiguration.

For organizations that want the highest level of security and performance, Magic WAN can be combined with Cloudflare Network Interconnect Partners for a private, secure and reliable layer 2 network between Cloudflare’s edge and our customers’ network. Private connectivity is one more weapon in building out defense in depth for your network.

Last year, we announced our first round of our Network Interconnection Partnerships. Today, we’re adding Digital Realty, CoreSite, EdgeConneX, 365 Data Centers, BBIX, Teraco, and Netrality Data Centers to provide:

• Colocation with Cloudflare in 70 locations

• Reduced cross connect lead times

• Connectivity reference architectures

With our new partnerships, customers now have more choice to connect privately and securely either via cloud exchanges (a software defined VLAN ordered via dashboard) or with private physical connectivity.

“The combination of Cloudflare One and PlatformDIGITAL® opens up new opportunities for our customers to accelerate their digital transformation journey and address data gravity head-on.  Our industry manifesto outlined a roadmap to build new native capabilities for embracing multiple interconnection platforms in collaboration with the industry. Today’s announcement with Cloudflare marks a significant step forward towards executing on that vision. Cloudflare’s solutions for addressing issues such as data localization, compliance and security align closely with Digital Realty’s pervasive data center architecture PDx™ approach and will add further value to the rich connected data communities on our global platform.”- Chris Sharp, Chief Technology Officer, Digital Realty

“CoreSite’s collaboration with Cloudflare provides customers with the high-speed direct fiber interconnection and enhanced security they need to meet the strictest performance and compliance requirements supporting modern hybrid applications. We are excited to enable Cloudflare Network Interconnect services within our network-dense, cloud-enabled Los Angeles and Denver data center campuses.”- Maile Kaiser, SVP — Sales, Coresite

We’re excited to announce this partnership as Cloudflare’s vision to ‘help build a better Internet’ deeply resonates with BBIX’s philosophy. In an environment of increased network security threats, our customers need to rely on highly reliable security solutions like Magic Transit to keep their businesses operating seamlessly. We believe this partnership will leverage the value of both companies and help us meet growing and diverse market demands.— Michikazu Fukuchi, Executive Vice President, Board Director and COO of BBIX, Inc.

Over the last 10 years, Cloudflare has built one of the fastest, most reliable, and most secure networks in the world. This week we have announced several more performance and security features that customers can leverage for their global security and networking needs. The Network On-ramp Partnerships launch provides private, secure and high performance options to connect your traffic sources to Cloudflare.

To join our list of On-ramp Partners, please reach out to us at onramppartners@cloudflare.com. We would love to hear more about the platforms you use and would like to see us integrate with - reach out to us here.

If you’d like to learn more about our Network On-ramp Partners, physical PNIs/CNIs, partner/virtual CNIs and how they integrate with Magic WAN, contact your account team or reach out to interconnection@cloudflare.com. To learn more about Magic WAN, please fill out the Contact Us form on the product page.

Cloudflare’s mission is to help build a better Internet. We’ve been at it since 2009 and we’re making progress — with approximately 25 million Internet properties being secured and accelerated by our platform.

When we look at other companies that not only have the scale to impact the Internet, but who are also on a similar mission, it’s hard to ignore Automattic, maintainers of the ubiquitous open-source WordPress software and owner of one the web’s largest WordPress hosting platforms WordPress.com, where up to 409 million people read 20 billion pages every month.¹

When we started brainstorming ways to combine our impact, one shared value stood out: privacy. We both share a vision for a more private Internet. Today we’re excited to announce a number of initiatives, starting with the integration of Cloudflare’s privacy-first web analytics into WordPress.com. This integration gives WordPress.com publishers choice in how they collect usage data and derive insights about their visitors.

Figure 1) Cloudflare Web Analytics tracking code integrated in the WordPress.com dashboard

Figure 2) An example of Cloudflare Web Analytics in the Cloudflare dashboard.

This is not the first time we’ve launched a WordPress-focused product. In October, we introduced Automatic Platform Optimization for WordPress sites, a service that our testing has shown to improve the TTFB by up to 72%!  This feature has been incredibly popular with our shared customer base and so we continued to look for ways to bring our two platforms closer together.

Starting today, Cloudflare Web Analytics settings will appear under the Marketing area of the WordPress.com dashboard, meaning users can simply paste in the analytics code snippet and WordPress.com will take care of injecting the code into their site at runtime. Users will also see links throughout the dashboard to Cloudflare APO and Cloudflare’s CDN, which they can enable within the Cloudflare dashboard.

Figure 3) Additional links to Cloudflare performance and security features in the WordPress.com dashboard

WordPress.com + Cloudflare has always been a best-of-breed collaboration, combining security and performance on one hand, with the world’s leading content management and publishing platform on the other. Integrating privacy-first web analytics with native support in the WordPress.com platform is just the latest step towards a better Internet.

To learn more and get started, visit our landing page.

¹https://wordpress.com/activity/

In addition to our physical locations, our customers can now interconnect with us at any of 23 metro areas across five continents using software-defined layer 2 networking technology. Following the recent release of CNI (which includes PNI support for Magic Transit), customers can now order layer 3 DDoS protection in any of the markets below, without requiring physical cross connects, providing private and secure links, with simpler setup.

We’re very excited to announce that five of the world's premier interconnect platforms are available at launch. Console Connect by PCCW Global in 14 locations, Megaport in 14 locations, PacketFabric in 15 locations, Equinix ECX Fabric™ in 8 locations and Zayo Tranzact in 3 locations, spanning North America, Europe, Asia, Oceania and Africa.

What is an Interconnection Platform?

Like much of the networking world, there are many terms in the interconnection space for the same thing: Cloud Exchange, Virtual Cross Connect Platform and Interconnection Platform are all synonyms. They are platforms that allow two networks to interconnect privately at layer 2, without requiring additional physical cabling. Instead the customer can order a port and a virtual connection on a dashboard, and the interconnection ‘fabric’ will establish the connection. Since many large customers are already connected to these fabrics for their connections to traditional Cloud providers, it is a very convenient method to establish private connectivity with Cloudflare.

Cloudflare has an extensive peering infrastructure and already has private links to thousands of other networks. Virtual private interconnection is particularly attractive to customers with strict security postures and demanding performance requirements, but without the added burden of ordering and managing additional physical cross connects and expanding their physical infrastructure.

SecureSimilar to physical PNI, traffic does not pass across the Internet. Rather, it flows from the customer router, to the Interconnection Platform’s network and ultimately to Cloudflare. So while there is still some element of shared infrastructure, it’s not over the public Internet.

EfficientModern PNIs are typically a minimum of 1Gbps, but if you have the security motivation without the sustained 1Gbps data transfer rates, then you will have idle capacity. Virtual connections provide for “sub-rate” speeds, which means less than 1Gbps, such as 100Mbps, meaning you only pay for what you use. Most providers also allow some level of “burstiness”, which is to say you can exceed that 100Mbps limit for short periods.

PerformanceBy avoiding the public Internet, virtual links avoid Internet congestion.

PriceThe major cloud providers typically have different pricing for egressing data to the Internet compared to an Interconnect Platform. By connecting to your cloud via an Interconnect Partner, you can benefit from those reduced egress fees between your cloud and the Interconnection Platform. This builds on our Bandwidth Alliance to give customers more options to continue to drive down their network costs.

Less OverheadBy virtualizing, you reduce physical cable management to just one connection into the Interconnection Platform. From there, everything defined and managed in software. For example, ordering a 100Mbps link to Cloudflare can be a few clicks in a Dashboard, as would be a 100Mbps link into Salesforce.

Data Center IndependenceIs your infrastructure in the same metro, but in a different facility to Cloudflare? An Interconnection Platform can bring us together without the need for additional physical links.

1. In any of our physical facilities

2. In any of the 23 metro areas where we are currently connected to an Interconnection Platform (see below)

3. If you’d like to connect virtually in a location not yet listed below, simply get in touch via our interconnection page and we’ll work out the best way to connect.

The metro areas below have currently active connections. New providers and locations can be turned up on request.

Our customers have been asking for direct on-ramps to our global network for a long time and we’re excited to deliver that today with both physical and virtual connectivity of the world’s leading interconnection Platforms.

Already a Cloudflare customer and connected with one of our Interconnection partners? Then contact your account team today to get connected and benefit from improved reliability, security and privacy of Cloudflare Network Interconnect via our interconnection partners.

Are you an Interconnection Platform with customers demanding direct connectivity to Cloudflare? Head to our partner program page and click “Become a partner”. We’ll continue to add platforms and partners according to customer demand.

"Equinix and Cloudflare share the vision of software-defined, virtualized and API-driven network connections. The availability of Cloudflare on the Equinix Cloud Exchange Fabric demonstrates that shared vision and we’re excited to offer it to our joint customers today."– Joseph Harding, Equinix, Vice President, Global Product & Platform MarketingSoftware Developer

"Cloudflare and Megaport are driven to offer greater flexibility to our customers. In addition to accessing Cloudflare’s platform on Megaport’s global internet exchange service, customers can now provision on-demand, secure connections through our Software Defined Network directly to Cloudflare Network Interconnect on-ramps globally. With over 700 enabled data centres in 23 countries, Megaport extends the reach of CNI onramps to the locations where enterprises house their critical IT infrastructure. Because Cloudflare is interconnected with our SDN, customers can point, click, and connect in real time. We’re delighted to grow our partnership with Cloudflare and bring CNI to our services ecosystem — allowing customers to build multi-service, securely-connected IT architectures in a matter of minutes."– Matt Simpson, Megaport, VP of Cloud Services

“The ability to self-provision direct connections to Cloudflare’s network from Console Connect is a powerful tool for enterprises as they come to terms with new demands on their networks. We are really excited to bring together Cloudflare’s industry-leading solutions with PCCW Global’s high-performance network on the Console Connect platform, which will deliver much higher levels of network security and performance to businesses worldwide.”– Michael Glynn, PCCW Global, VP of Digital Automated Innovation

"Our customers can now connect to Cloudflare via a private, secure, and dedicated connection via the PacketFabric Marketplace. PacketFabric is proud to be the launch partner for Cloudflare's Interconnection program. Our large U.S. footprint provides the reach and density that Cloudflare customers need."– Dave Ward, PacketFabric CEO

When your server goes down, it’s a big problem. Today, Cloudflare is introducing two new tools to help you understand and respond faster to origin downtime — plus, a new service to automatically avoid downtime.

The new features are:

• Standalone Health Checks, which notify you as soon as we detect problems at your origin server, without needing a Cloudflare Load Balancer.

• Passive Origin Monitoring, which lets you know when your origin cannot be reached, with no configuration required.

• Zero-Downtime Failover, which can automatically avert failures by retrying requests to origin.

Our first new tool is Standalone Health Checks, which will notify you as soon as we detect problems at your origin server -- without needing a Cloudflare Load Balancer.

A Health Check is a service that runs on our edge network to monitor whether your origin server is online. Health Checks are a key part of our load balancing service because they allow us to quickly and actively route traffic to origin servers that are live and ready to serve requests. Standalone Health Checks allow you to monitor the health of your origin even if you only have one origin or do not yet need to balance traffic across your infrastructure.

We’ve provided many dimensions for you to hone in on exactly what you’d like to check, including response code, protocol type, and interval. You can specify a particular path if your origin serves multiple applications, or you can check a larger subset of response codes for your staging environment. All of these options allow you to properly target your Health Check, giving you a precise picture of what is wrong with your origin.

If one of your origin servers becomes unavailable, you will receive a notification letting you know of the health change, along with detailed information about the failure so you can take action to restore your origin’s health.  

Lastly, once you’ve set up your Health Checks across the different origin servers, you may want to see trends or the top unhealthy origins. With Health Check Analytics, you’ll be able to view all the change events for a given health check, isolate origins that may be top offenders or not performing at par, and move forward with a fix. On top of this, in the near future, we are working to provide you with access to all Health Check raw events to ensure you have the detailed lens to compare Cloudflare Health Check Event logs against internal server logs.

Users on the Pro, Business, or Enterprise plan will have access to Standalone Health Checks and Health Check Analytics to promote top-tier application reliability and help maximize brand trust with their customers. You can access Standalone Health Checks and Health Check Analytics through the Traffic app in the dashboard.

Standalone Health Checks are a super flexible way to understand what’s happening at your origin server. However, they require some forethought to configure before an outage happens. That’s why we’re excited to introduce Passive Origin Monitoring, which will automatically notify you when a problem occurs -- no configuration required.

Cloudflare knows when your origin is down, because we’re the ones trying to reach it to serve traffic! When we detect downtime lasting longer than a few minutes, we’ll send you an email.

Starting today, you can configure origin monitoring alerts to go to multiple email addresses. Origin Monitoring alerts are available in the new Notification Center (more on that below!) in the Cloudflare dashboard:

Passive Origin Monitoring is available to customers on all Cloudflare plans.

What’s better than getting notified about downtime? Never having downtime in the first place! With Zero-Downtime Failover, we can automatically retry requests to origin, even before Load Balancing kicks in.

How does it work? If a request to your origin fails, and Cloudflare has another record for your origin server, we’ll just try another origin within the same HTTP request. The alternate record could be either an A/AAAA record configured via Cloudflare DNS, or another origin server in the same Load Balancing pool.

Consider an website, example.com, that has web servers at two different IP addresses: 203.0.113.1 and 203.0.113.2. Before Zero-Downtime Failover, if 203.0.113.1 becomes unavailable, Cloudflare would attempt to connect, fail, and ultimately serve an error page to the user. With Zero-Downtime Failover, if 203.0.113.1 cannot be reached, then Cloudflare’s proxy will seamlessly attempt to connect to 203.0.113.2. If the second server can respond, then Cloudflare can avert serving an error to example.com’s user.

Since we rolled Zero-Downtime Failover a few weeks ago, we’ve prevented tens of millions of requests per day from failing!

Zero-Downtime Failover works in conjunction with Load Balancing, Standalone Health Checks, and Passive Origin Monitoring to keep your website running without a hitch. Health Checks and Load Balancing can avert failure, but take time to kick in. Zero-Downtime failover works instantly, but adds latency on each connection attempt. In practice, Zero-Downtime Failover is helpful at the start of an event, when it can instantly recover from errors; once a Health Check has detected a problem, a Load Balancer can then kick in and properly re-route traffic. And if no origin is available, we’ll send an alert via Passive Origin Monitoring.

To see an example of this in practice, consider an incident from a recent customer. They saw a spike in errors at their origin that would ordinarily cause availability to plummet (red line), but thanks to Zero-Downtime failover, their actual availability stayed flat (blue line).

During a 30 minute time period, Zero-Downtime Failover improved overall availability from 99.53% to 99.98%, and prevented 140,000 HTTP requests from resulting in an error.

It’s important to note that we only attempt to retry requests that have failed during the TCP or TLS connection phase, which ensures that HTTP headers and payload have not been transmitted yet. Thanks to this safety mechanism, we're able to make Zero-Downtime Failover Cloudflare's default behavior for Pro, Business, and Enterprise plans. In other words, Zero-Downtime Failover makes connections to your origins more reliable with no configuration or action required.

Our customers are always asking us for more insights into the health of their critical edge infrastructure. Health Checks and Passive Origin monitoring are a significant step towards Cloudflare taking a proactive instead of reactive approach to insights.

To support this work, today we’re announcing the Notification Center as the central place to manage notifications. This is available in the dashboard today, accessible from your Account Home.

From here, you can create new notifications, as well as view any existing notifications you’ve already set up. Today’s release allows you to configure  Passive Origin Monitoring notifications, and set multiple email recipients.

We’re excited about today’s launches to helping our customers avoid downtime. Based on your feedback, we have lots of improvements planned that can help you get the timely insights you need:

• New notification delivery mechanisms

• More events that can trigger notifications

• Advanced configuration options for Health Checks, including added protocols, threshold based notifications, and threshold based status changes.

• More ways to configure Passive Health Checks, like the ability to add thresholds, and filter to specific status codes

I'm the Product Manager for the Application Services team here at Cloudflare. We recently identified a need for a new tool around service ownership. As a fast-growing engineering organization, ownership of services changes fairly frequently. Many cycles get burned in chat with questions like "Who owns service x now?

Whilst it's easy to see how a tool like this saves a few seconds per day for the asker and askee, and saves on some mental context switches, the time saved is unlikely to add up to the cost of development and maintenance.

= 5 minutes per day
x 260 work days 
= 1300 mins 
/ 60 mins 
= 20 person hours per year

So a 20-hour investment in that tool would pay itself back in a year valuing everyone's time the same. While we've made great strides in improving the efficiency of building tools at Cloudflare, 20 hours is a stretch for an end-to-end build, deploy and operation of a new tool.

The more I use Serverless and Workers, the more I'm struck with the benefits of:

When I upload a Worker, it's automatically distributed to 175+ data centers. I don't have to be worried about uptime - it will be up, and it will be fast.

With operational overhead largely removed, I'm able to focus purely on code. A constrained problem space like this lends itself really well to Workers. I reckon we can knock this out in well under 20 hours.

At Cloudflare, people ask these questions in Chat, so that's a natural interface to service ownership. Here's the spec:

Following the Hangouts Chat API Guide, let's start with a hello world bot.

1. To configure the bot, go to the Publish page and scroll down to the Enable The API button:

2. Enter the bot name

3. Download the private key JSON file

4. Go to the API Console

5. Search for the Hangouts Chat API (Note: not the Google+ Hangouts API)

   

6. Click Configuration on the left menu

7. Fill out the form as per below [1]

   • Use a hard to guess URL. I generate a guide and use that in the URL.

   • The URL will be the route you associate with your Worker in the Dashboard

     

8. Click Save

So Google Chat should know about our bot now. Back in Google Chat, click in the "Find people, rooms, bots" text box and choose "Message a Bot". Your bot should show up in the search:

It won't be too useful just yet, as we need to create our Worker to receive the messages and respond!

In the Workers dashboard, create a script and associate with the route you defined in step #7 (the one with the guide). It should look something like below. [2]

The Google Chatbot interface is pretty simple, but weirdly obfuscated in the Hangouts API guide IMHO. You have to reverse engineer the python example.

Basically, if we message our bot like @ownerbot-blog Kibana, we'll get a message like this:

  {
    "type": "MESSAGE",
    "message": {
      "argumentText": "Kibana"
    }
  }

To respond, we need to respond with 200 OK and JSON body like this:

content-length: 27
content-type: application/json

{"text":"Hello chat world"}

So, the minimum Chatbot Worker looks something like this:

addEventListener('fetch', event => { event.respondWith(process(event.request)) });

function process(request) {
  let body = {
	text: "Hello chat world"
  }
  return new Response(JSON.stringify(body), {
    status: 200,
    headers: {
        "Content-Type": "application/json",
        "Cache-Control": "no-cache"
    }
  });
}

Save and deploy that, and we should be able to message our bot:

Success!

OK, on to the meat of the code. Based on the requirements, I see a need for an AddCommand, QueryCommand, DeleteCommand and HelpCommand. I also see some sort of ServiceDirectory that knows how to add, delete and retrieve services.

I created a CommandFactory which accepts a ServiceDirectory, as well as an implementation of a KV store, which will be Workers KV in production, but I'll mock out in tests.

class CommandFactory {
    constructor(serviceDirectory, kv) {
        this.serviceDirectory = serviceDirectory;
        this.kv = kv;
    }

    create(argumentText) {
        let parts = argumentText.split(' ');
        let primary = parts[0];       
        
        switch (primary) {
            case "add":
                return new AddCommand(argumentText, this.serviceDirectory, this.kv);
            case "delete":
                return new DeleteCommand(argumentText, this.serviceDirectory, this.kv);
            case "help":
                return new HelpCommand(argumentText, this.serviceDirectory, this.kv);
            default:
                return new QueryCommand(argumentText, this.serviceDirectory, this.kv);
        }
    }
}

OK, so if we receive a message like @ownerbot add, we'll interpret it as an AddCommand, but if it's not something we recognize, we'll assume it's a QueryCommand like @ownerbot Kibana which makes it easy to parse commands.

OK, our commands need a service directory, which will look something like this:

class ServiceDirectory {     
    get(serviceName) {...}
    async add(service) {...}
    async delete(serviceName) {...}
    find(serviceName) {...}
    getNames() {...}
}

Let's build some commands. Oh, and my chatbot is going to be Ultima IV themed, because... reasons.

class AddCommand extends Command {

    async respond() {
        let cmdParts = this.commandParts;
        if (cmdParts.length !== 6) {
            return new OwnerbotResponse("Adding a service requireth Name, Owner, Room Name and Google Chat Room Url.", false);
        }
        let name = this.commandParts[1];
        let owner = this.commandParts[2];
        let room = this.commandParts[3];
        let url = this.commandParts[4];
        let aliasesPart = this.commandParts[5];
        let aliases = aliasesPart.split(' ');
        let service = {
            name: name,
            owner: owner,
            room: room,
            url: url,
            aliases: aliases
        }
        await this.serviceDirectory.add(service);
        return new OwnerbotResponse(`My codex of knowledge has expanded to contain knowledge of ${name}. Congratulations virtuous Paladin.`);
    }
}

The nice thing about the Command pattern for chatbots, is you can encapsulate the logic of each command for testing, as well as compose series of commands together to test out conversations. Later, we could extend it to support undo. Let's test the AddCommand

  it('requires all args', async function() {
            let addCmd = new AddCommand("add AdminPanel 'Internal Tools' 'Internal Tools'", dir, kv); //missing url            
            let res = await addCmd.respond();
            console.log(res.text);
            assert.equal(res.success, false, "Adding with missing args should fail");            
        });

        it('returns success for all args', async function() {
            let addCmd = new AddCommand("add AdminPanel 'Internal Tools' 'Internal Tools Room' 'http://chat.google.com/roomXYZ'", dir, kv);            
            let res = await addCmd.respond();
            console.debug(res.text);
            assert.equal(res.success, true, "Should have succeeded with all args");            
        });

$ mocha -g "AddCommand"
  AddCommand
    add
      ✓ requires all args
      ✓ returns success for all args
  2 passing (19ms)

So far so good. But adding commands to our ownerbot isn't going to be so useful unless we can query them.

class QueryCommand extends Command {
    async respond() {
        let service = this.serviceDirectory.get(this.argumentText);
        if (service) {
            return new OwnerbotResponse(`${service.owner} owns ${service.name}. Seeketh thee room ${service.room} - ${service.url})`);
        }
        let serviceNames = this.serviceDirectory.getNames().join(", ");
        return new OwnerbotResponse(`I knoweth not of that service. Thou mightst asketh me of: ${serviceNames}`);
    }
}

Let's write a test that runs an AddCommand followed by a QueryCommand

describe ('QueryCommand', function() {
    let kv = new MockKeyValueStore();
    let dir = new ServiceDirectory(kv);
    await dir.init();

    it('Returns added services', async function() {    
        let addCmd = new AddCommand("add AdminPanel 'Internal Tools' 'Internal Tools Room' url 'alias' abc123", dir, kv);            
        await addCmd.respond();

        let queryCmd = new QueryCommand("AdminPanel", dir, kv);
        let res = await queryCmd.respond();
        assert.equal(res.success, true, "Should have succeeded");
        assert(res.text.indexOf('Internal Tools') > -1, "Should have returned the team name in the query response");
    })
})

A lot of the code as been elided for brevity, but you can view the full source on GitHub. Let's take it for a spin!

Some of the things I learned during the development of @ownerbot were:

• Chatbots are an awesome use case for Serverless. You can deploy and not worry again about the infrastructure

• Workers KV means extends the range of useful chatbots to include stateful bots like @ownerbot

• The Command pattern provides a useful way to encapsulate the parsing and responding to commands in a chatbot.

In Part 2 we'll add authentication to ensure we're only responding to requests from our instance of Google Chat

1. For simplicity, I'm going to use a static shared key, but Google have recently rolled out a more secure method for verifying the caller's authenticity, which we'll expand on in Part 2. ↩︎

2. This UI is the multiscript version available to Enterprise customers. You can still implement the bot with a single Worker, you'll just need to recognize and route requests to your chatbot code. ↩︎

It can be a big deal for Internet users when Cloudflare rolls into town. After our recent Mongolia launch, we received lots of feedback from happy customers that all of a sudden, Internet performance noticeably improved.

As a result, it's not a surprising that we regularly receive requests from all over the world to either peer with our network, or to host a node. However, potential partners are always keen to know just how much traffic will be served over that link. What performance benefits can end-users expect? How much upstream traffic will the ISP save? What new bandwidth will they have available for traffic management?

Starting today, ISPs and hosting providers can request a login to the Cloudflare Peering Portal to find the answers to these questions. After validating ownership of your ASN, the Cloudflare network team will provide a login to the newly launched Peering Portal - Beta. You can find more information at: cloudflare.com/partners/peering-portal/

If you're new to the core infrastructure of the Internet, the best way to understand peering is to frame the problems it solves:

1. Bandwidth costs money

2. Internet users don't like slow websites

3. Network operators have limited resources

Consider what happens if you request a site hosted on Cloudflare from home:

• The domain resolves to a Cloudflare IP

• Your browser sends an HTTP request to that IP

• Your ISP's routers consult their routing table and route the packets upstream to their transit provider (COSTS MONEY)

• The packets traverse multiple hops to the nearest Cloudflare POP (TAKES TIME)

• Those packets are taking up some of the ISPs capacity, making it unavailable for other competing packets (TRAFFIC MANAGEMENT)

As Cloudflare continues to grow, we represent an ever-increasing share of the Internet's traffic. A Network Administrator reviewing his or her network, will see this represented as an increasing cost of bandwidth, of slower than optimal request times and of bandwidth not able to be allocated for other competing traffic.

To address these problems, large networks, hosting providers and CDNs will peer with each other. That is, to interconnect their networks directly. Put another way, cut out the middleman. If I request a site on Cloudflare and my ISP is already directly connected to the Cloudflare network, the packet will traverse fewer hops, my website will load faster, my ISP will pay less to their transit provider and they can allocate that bandwidth for other sites.

There are a few different types of peering. The simplest way to conceptualize is plugging in a dedicated cable to exchange data directly between two networks. Practically, there a few ways it happens:

If Cloudflare and the potential peering partner have equipment in the same data center, we can setup a "Private Network Interconnect", which involves dedicated cabling and network configuration.

PNI: Private Network Interconnect

An Internet exchange point (IxP) is a physical location through which Internet companies such as Internet Service Providers (ISPs) and CDNs connect with each other. It typically involves a switching-fabric, that Cloudflare is already connected to. If our potential peering partner is also present in the IxP, setting up peering is a simple as network configuration, with no additional cabling required.

Internet Exchange Point (IxP)

There are scenarios where neither PNI nor IxP peering is feasible, such as when Cloudflare and our potential partners are not present in the same physical location. In these cases, our partner can request to host Cloudflare equipment in their own data center racks. Once commissioned, the equipment effectively operates as if it were a Cloudflare data center (PoP). The cache will populate and all of our performance and reliability services will execute right there, close to our peering partner's customer.

Hosting a node

Peering still has some costs - particularly an administrative burden. The Network Administrators have to agree the details. Commercial teams may require contractual agreements. The link has to be monitored. Therefore, most large networks will have a peering policy and prioritize peering with the networks with which they exchange the most data and will thus generate the most mutual value.

This is especially true for hosting nodes. In addition to the configuration and contractual agreements, there is the logistical effort of receiving and configuring equipment.

The Peering Portal - Beta, released today, allows any ASN (Autonomous System Number) network to view detailed statistics on transit data between it and Cloudflare. Existing partners can use it to review existing session data and statistics and prospective partners can use it to estimate potential transit cost savings, performance improvements and the freeing up of upstream bandwidth to use for other traffic.

The Peering Portal allows both existing and prospective partners to see:

This view shows both growth over time, and the relative traffic for each location.

Time series traffic data

Peering sessions outline how many sessions are established in various locations.

Session Statistics

At a glance view of where data flows in- and out- of connections to Cloudflare from your ASN.

Relative Traffic Weight by Peering Location

We plan to add many more statistics over time.

So, whether you're a current peering partner who'd like more insight into your current traffic with Cloudflare, or a future partner who'd like to explore the performance, financial and traffic management benefits of peering with Cloudflare, or hosting a node visit cloudflare.com/partners/peering-portal and request a login.

You can also review our peering policy here.

The Workers team just announced support for WebAssembly (WASM) within Workers. If you saw my post on Internet Native Apps, you'll know that I believe WebAssembly will play a big part in the apps of the future.

It's exciting times for Rust developers. Cloudflare's Serverless Platform, Cloudflare Workers, allows you to compile your code to WASM, upload to 150+ data centers and invoke those functions just as easily as if they were JavaScript functions. Today I'm going to convert my lipsum generator to use Rust and explore the developer experience (hint: it's already pretty nice).

The Workers teams notes in the documentation:

...WASM is not always the right tool for the job. For lightweight tasks like redirecting a request to a different URL or checking an authorization token, sticking to pure JavaScript is probably both faster and easier than WASM. WASM programs operate in their own separate memory space, which means that it's necessary to copy data in and out of that space in order to operate on it. Code that mostly interacts with external objects without doing any serious "number crunching" likely does not benefit from WASM.

OK, I'm unlikely to gain significant performance improvements on this particular project, but it serves as a good opportunity illustrate the developer experience and tooling. ?

Coding with WASM has been bleeding edge for a while, but Rust's tool for WASM development recently reached a fairly ergonomic state and even got a website. Make sure you have the prerequisites installed and then follow the steps below to get started.

wasm-pack allows you to compile Rust to WebAssembly, as well as generate bindings between JavaScript objects and Rust objects. We'll talk about why that's important later.

# Install wasm-pack
curl https://rustwasm.github.io/wasm-pack/installer/init.sh -sSf | sh

# Cargo generate to build apps based on templates
cargo install cargo-generate

# And generate a HelloWorld wasm app, based on the wasm-pack template
cargo generate --git https://github.com/rustwasm/wasm-pack-template

?  Project Name: bob-ross-lorem-ipsum-rust
?   Creating project called `bob-ross-lorem-ipsum-rust`...
✨   Done! New project created /Volumes/HD2/Code/cloudflare/bobross/bob-ross-lipsum-rust/api-rust/bob-ross-lorem-ipsum-rust

The WASM book describes some of the glue in the Cargo.toml file, but the meat of the project is here:

...
#[wasm_bindgen]
extern {
    fn alert(s: &str);
}

#[wasm_bindgen]
pub fn greet() {
    alert("Hello, bob-ross-lorem-ipsum-rust!");
}

This does two things

1. Binds to the "external" function in our host environment where the WASM will run. If that's the browser, it will popup a window.

2. It also defines a Rust function, greet() which will be made available as a function callable from the host environment, in our case JavaScript.

Build with wasm-pack build

$ wasm-pack build
  
  [1/9] ?  Checking `rustc` version...
  [2/9] ?  Checking crate configuration...
  [3/9] ?  Adding WASM target...
  [4/9] ?  Compiling to WASM...
  [5/9] ?  Creating a pkg directory...
  [6/9] ?  Writing a package.json...
  ⚠️   [WARN]: Field 'description' is missing from Cargo.toml. It is not necessary, but recommended
  ⚠️   [WARN]: Field 'repository' is missing from Cargo.toml. It is not necessary, but recommended
  ⚠️   [WARN]: Field 'license' is missing from Cargo.toml. It is not necessary, but recommended
  [7/9] ?  Copying over your README...
  [8/9] ⬇️  Installing wasm-bindgen...
  [9/9] ?‍♀️  Running WASM-bindgen...
  ✨   Done in 2 minutes
| ?   Your wasm pkg is ready to publish at "/Volumes/HD2/Code/cloudflare/bobross/bob-ross-lipsum-rust/bob-ross

Subsequent builds will be faster. We eventually want to ship that .wasm file to a Worker, but I'd like to keep things local and test in a browser first.

There's an npm package that will create a templated webpack webapp, preconfigured to import WebAssembly node modules, which we'll use as a test harness.

$ npm init wasm-app www
npx: installed 1 in 2.533s
? Rust + ? Wasm = ❤

Install the dependencies with npm install and then npm start to fire up the webpack bundled web server to serve your page

$ npm start

> create-wasm-app@0.1.0 start /Volumes/HD2/Code/cloudflare/bobross/bob-ross-lipsum-rust/bob-ross-lorem-ipsum-rust/www
> webpack-dev-server

ℹ ｢wds｣: Project is running at http://localhost:8080/

Open your web browser at http://localhost:8080 and you should see your first WASM generated content!

OK, that's promising, but it's not actually our code. Our greet function returned "Hello, bob-ross-lorem-ipsum-rust!"

If we open up www/index.js, we can see this:

import * as wasm from "hello-wasm-pack";

wasm.greet();

So it's importing a node module "hello-wasm-pack" which was part of the template. We want to import our own module we built with cargo generate earlier.

First, expose our WASM package as a node module:

# Create a global node_modules entry pointing to your local wasm pkg
$ cd pkg
$ npm link
...
/Users/steve/.nvm/versions/node/v8.11.3/lib/node_modules/bob-ross-lorem-ipsum-rust -> /Volumes/HD2/Code/cloudflare/bob-ross-lorem-ipsum-rust/pkg

Then make it available as a node_module in our test harness.

$ cd ../www
$ npm link bob-ross-lorem-ipsum-rust
/Volumes/HD2/Code/cloudflare/bobross/bob-ross-lorem-ipsum-rust/www/node_modules/bob-ross-lorem-ipsum-rust -> /Users/steve/.nvm/versions/node/v8.11.3/lib/node_modules/bob-ross-lorem-ipsum-rust -> /Volumes/HD2/Code/cloudflare/bobross/bob-ross-lorem-ipsum-rust/pkg

Import it in the index.js file

//import * as wasm from "hello-wasm-pack";
import * as wasm from "bob-ross-lorem-ipsum-rust"

and run!

npm run build
npm run start

Better! That's our code.

We have:

• A Hello, World WASM module

• Exposed as an npm module

• A webpack app which imports that module

• And invokes the greet() function

We're now going to port our Bob Ross Lorem Ipsum generator to Rust, and try it out locally before uploading as a worker. Check it out on in the GitHub repo, or follow along.

use std::vec::Vec;
use rand::distributions::{Range, Distribution};
use rand::rngs::SmallRng;
use rand::FromEntropy;

static PHRASES: [&str; 370] = [...elided for clarity];

fn get_random_indexes(cnt: usize) -> Vec<usize> {
    let mut rng = get_rng();
    let range = Range::new(0, PHRASES.len());    
    (0..cnt)
        .map(|_| range.sample(&mut rng))
        .collect()
}

fn get_phrase(idx: usize) -> &'static str {
    PHRASES[idx]        
}

fn get_rng() -> SmallRng {    
    SmallRng::from_entropy()
}

fn get_phrases(idxs: &Vec<usize>) -> Vec<&'static str> {    
    idxs.iter()
        .map(|idx| get_phrase(*idx))
        .collect()
}

fn need_newline(newline: usize, idx: usize) -> bool {
    //idx+1 because idx is zero-based but we want a new line after "every x phrases".
    (newline > 0) && (idx > 0) && ((idx + 1) % newline == 0)
}

fn need_space(newline: usize, idx: usize) -> bool {
    !need_newline(newline, idx)
}

fn build_phrase_text(idxs: Vec<usize>, newline: usize) -> String {
    let phrases_vec = get_phrases(&idxs);
    let mut string = String::new();
    for i in 0..phrases_vec.len() {
        //the phrase
        string.push_str(phrases_vec[i]);
        //spaces between phrases
        if need_space(newline, i) {
            string.push(' ');
        }
        //new lines
        if need_newline(newline, i) {
            string.push_str("\n\n");
        }
    }
    string
}

pub fn get_phrase_text(phrase_cnt: usize, newline: usize) -> String {
    let idxs = get_random_indexes(phrase_cnt);
    build_phrase_text(idxs,newline)
}

#[cfg(test)]
mod tests {
    use super::*;

    fn get_test_indexes() -> Vec<usize> {
        vec![34, 2, 99, 43, 128, 300, 45, 56, 303, 42, 11]
    }
    
    #[test]
    fn get_phrases() {
        let randoms = get_test_indexes();
        let phrases = super::get_phrases(&randoms);
        println!("{:?}", phrases);
    }
}

Running the tests shows everything looks good:

$ cargo test -- --nocapture
    Finished dev [unoptimized + debuginfo] target(s) in 0.40s                                                                                       
     Running target/debug/deps/bob_ross_lorem_ipsum_rust-5be29ab9ead7494d

running 1 test
["Decide where your cloud lives. Maybe he lives right in here.", "A fan brush is a fantastic piece of equipment. Use it. Make friends with it.", "If we\'re going to have animals around we all have to be concerned about them and take care of them.", "Don\'t kill all your dark areas - you need them to show the light.", "It\'s almost like something out of a fairytale book.", "We don\'t have anything but happy trees here.", "Even the worst thing we can do here is good.", "Everything is happy if you choose to make it that way.", "We don\'t make mistakes we just have happy little accidents.", "Don\'t hurry. Take your time and enjoy.", "All you have to learn here is how to have fun."]
test phrases::tests::get_phrases ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

And I've exposed the method to WASM like this:

#[wasm_bindgen]
pub fn get_phrase_text(phrase_cnt: usize, new_line: usize) -> String {
    phrases::get_phrase_text(phrase_cnt, new_line)
}

So, we should be good to call our WASM from the browser test harness. Let's modify www/index.js to invoke get_phrase_text and fire it up in the browser!

//wasm.greet();
let phraseText = wasm.get_phrase_text(100, 10);
console.log(phraseText);
alert(phraseText);

Fail.

If you've played around with Rust, you'll know how jarring it can be to see your code compile and tests pass, only to have it blow up at runtime. The strictness of the language means your code behaves exactly as you expect more often than other languages, so this failure really threw me.

Analysing the stack trace, we can see the failure starts at FromEntropy. My first instinct was that the WASM host didn't support providing entropy. I re-jigged the code to use a time-based seed instead and that failed too. The common theme seemed to be both entropy, and the current time, both make system calls.

Reading through the relevant Github issues which discuss this here and here, it looks like the design for how Rust generated WASM will handle system calls remains open. If the compiler isn't able to guarantee the system calls will be available, shouldn't the linker fail to compile? I think the answer lies in the wasm-unknown-unknown triplet that we compile to. There are no guarantees on what the target platform provides when you target unknown, so you're on your own.

That said, we know that the v8 JavaScript engine will be our host in both the browser, and in Workers. There are libraries which allow us to make all Web APIs defined in the ECMAScript standard available to Rust, such as js-sys

Using that, I can rewrite the failing get_rng() method to return a pseudo-random number generated seed with a time-based value using the Date object provided by the JavaScript host, rather than making a system call. Full code listing is on Github

fn get_rng() -> SmallRng {    
    use js_sys::Date;
    use rand::SeedableRng;

	//from Javascript	
    let ticks = Date::now(); 
    //convert the number to byte array to use as a seed
    let tick_bytes = transmute(ticks as u128); 
    SmallRng::from_seed(tick_bytes)
}

After another wasm-pack build and reloading our test page...

Huzzah! OK, if my WASM module returns the right output in Chrome, I'm feeling good about it working in Workers.

You can use the API or UI to upload. Below, I upload the .wasm file in my /pkg director and bind it to the global variable BOBROSS_WASM, where it will be available in my Worker.

If you're following and looked at the output of the wasm-pack build command, you might have noticed it produced a JavaScript glue file in the pkg folder, which is actually what the browser executed.

It looks like this:

/* tslint:disable */
import * as wasm from './bob_ross_lorem_ipsum_rust_bg';

let cachedDecoder = new TextDecoder('utf-8');

let cachegetUint8Memory = null;
function getUint8Memory() {
    if (cachegetUint8Memory === null || cachegetUint8Memory.buffer !== wasm.memory.buffer) {
        cachegetUint8Memory = new Uint8Array(wasm.memory.buffer);
    }
    return cachegetUint8Memory;
}

function getStringFromWasm(ptr, len) {
    return cachedDecoder.decode(getUint8Memory().subarray(ptr, ptr + len));
}

export function __wbg_alert_8c454b1ebc6068d7(arg0, arg1) {
    let varg0 = getStringFromWasm(arg0, arg1);
    alert(varg0);
}
/**
* @returns {void}
*/
export function greet() {
    return wasm.greet();
}

let cachedGlobalArgumentPtr = null;
function globalArgumentPtr() {
    if (cachedGlobalArgumentPtr === null) {
        cachedGlobalArgumentPtr = wasm.__wbindgen_global_argument_ptr();
    }
    return cachedGlobalArgumentPtr;
}

let cachegetUint32Memory = null;
function getUint32Memory() {
    if (cachegetUint32Memory === null || cachegetUint32Memory.buffer !== wasm.memory.buffer) {
        cachegetUint32Memory = new Uint32Array(wasm.memory.buffer);
    }
    return cachegetUint32Memory;
}
/**
* @param {number} arg0
* @param {number} arg1
* @returns {string}
*/
export function get_phrase_text(arg0, arg1) {
    const retptr = globalArgumentPtr();
    wasm.get_phrase_text(retptr, arg0, arg1);
    const mem = getUint32Memory();
    const rustptr = mem[retptr / 4];
    const rustlen = mem[retptr / 4 + 1];

    const realRet = getStringFromWasm(rustptr, rustlen).slice();
    wasm.__wbindgen_free(rustptr, rustlen * 1);
    return realRet;

}

const __wbg_now_4410283ed4cdb45a_target = Date.now.bind(Date) || function() {
    throw new Error(`wasm-bindgen: Date.now.bind(Date) does not exist`);
};

export function __wbg_now_4410283ed4cdb45a() {
    return __wbg_now_4410283ed4cdb45a_target();
}

It takes care of the marshalling of strings from WASM into JavaScript and freeing the memory it uses. In an ideal world, we'd just include this in our Worker and be done. However, there a few differences between how Workers instantiates WebAssembly modules and the browser.

You need to:

• Remove the import line

• Remove the export keywords

• Wrap all the functions in a module

• Create an importObject referencing the methods

• Pass that in when you create the WebAssembly instance

Update 28-Dec-2018: wasm-bindgen has been updated since this post. See this PR if you're getting errors related to the glue code. Thanks Andrew!

You can view a side-by-side diff or a patch to see the changes required to have it run in a Worker. Include the modified glue code into your worker and you can now call it like any other function. (Thanks for the tip Jake Riesterer!)

// Request Handler
async function handleRequest(request) {

    let url = new URL(request.url);

    //Serve the UI
    if (url.pathname === "/" ) {
        let init = { "status" : 200 , "headers" : { 'Content-Type': 'text/html' } };
        return new Response(ui, init);
    }

    let phraseCount = Math.min(parseInt(url.searchParams.get("phrases") || 100), 10000);
    let newLine = Math.min(parseInt(url.searchParams.get("newline") || 0), 10000);

    //Serverless Rust in 150+ data centers!
    let phraseText = mod.get_phrase_text(phraseCount, newLine);
    return new Response(phraseText);
}

Success!

The full source code is on Github.

We can compile Rust to WASM, and call it from Serverless functions woven into the very fabric of the Internet. That's huge and I can't wait to do more of it.

There's some wrangling of the generated code required, but the tooling will improve over time. Once you've modified the glue code, calling a function in Rust generated WASM modules is just as simple as JavaScript.

Are we Serverless yet? Yes we are.

In a future post, I'll extract out the phrases and the UI to the KV store to show a full fledged serverless app powered by Rust and WASM.

If you've not heard of Lorem Ipsum, it's an extract from a latin poem that designers use as placeholder text when designing the layout of a document. There are generators all over the web that will spit out as much text as you need.

Source: Wikipedia

Of course, the web being the web that we all love, there are also endless parodies of Lorem Ipsum. You can generate Hodor Ipsum, Cat Ipsum and Hipster Ipsum. I have a new, undisputed favourite: Bob Ross Ipsum.

Not growing up in the U.S., I hadn't come across the lovable, calm, serene and beautiful human that is Bob Ross. If you haven't spent 30 mins watching him paint a landscape, you should do that now. He built a following as host of the TV show “The Joy of Painting” which ran on the U.S. PBS channel from 1983-1994. He became famous for his relaxed approach to painting and his catch phrases like “Happy Little Trees”

Here's a sneak peek of the sort of language you'll hear. I feel better already!

Remember how free clouds are. They just lay around in the sky all day long. These things happen automatically. All you have to do is just let them happen. There are no mistakes. You can fix anything that happens. Volunteering your time; it pays you and your whole community fantastic dividends. You create the dream - then you bring it into your world. You can do anything here - the only prerequisite is that it makes you happy. A tree needs to be your friend if you're going to paint him. Nice little clouds playing around in the sky. Pretend you're water. Just floating without any effort. Having a good day. Nature is so fantastic, enjoy it. Let it make you happy.

OK, so it turned out the distressed engineer always uses Bob Ross Ipsum when he's building UIs. But the site was down!

My guess is the site got popular enough that the VPS wasn't worth paying, or the hosting provider didn't appreciate the traffic. As a well-trained Cloudflarian, my initial response was:

OK Step 1, stand on the shoulders of giants. Has anyone open sourced a Bob Ross Lorem Ipsum Generator?

$npm search "bob ross"
NAME                      | DESCRIPTION          | AUTHOR          | DATE       | VERSION  | KEYWORDS       
postcss-bob-ross-palette  | Bring a little Bob…  | =jonathantneal  | 2015-12-01 | 1.0.1    | postcss css pos
bob-ross                  | Bob Ross Color…      | =azz            | 2017-02-14 | 1.0.0    | Bob Ross Color 
hubot-ross                | A hubot script to…   | =tcrammond      | 2015-03-31 | 1.0.1    | hubot hubot scr
bob-ross-lipsum           | Phrases from Bob…    | =forresto       | 2016-01-15 | 1.1.1    | lorem ipsum

Of course they have! And the code is delightfully simple:

function getPhrase () {
  return phrases[Math.floor(Math.random()*phrases.length)]
}

function getPhrases (length) {
  if (!length) length = 1
  var happyPhrases = []
  for (var i=0; i<length; i++) {
    happyPhrases.push(getPhrase())
  }
  return happyPhrases.join(' ')
}

// Compiled by http://www.bobrosslipsum.com/ 2016 January
var phrases = [...elided for clarity...]

Assuming we've registered a domain and put it on Cloudflare, let's see how quickly can we get a globally distributed, highly available API running in 150+ data centers, to generate some Bob Ross Lorem Ipsum.

I'm going to:

1. Launch workers

2. Confirm I get console output

3. Put a test response

4. Paste in my code to generate Bob Ross Lorem Ipsum

5. Test it out

6. Add a route

7. Save*

8. Request it in the browser

* This pushes it to 150+ data centers... no biggie.

So it takes about 90 secs to build a basic Worker serving dynamically generated text from the Edge. It blows me away just how productive you can be with Cloudflare Workers. With a few clicks, we have code deployed to 150+ data centers and within 10ms of 90% of the world's Internet population. And it's fast.

The more I use it, the more it reminds of Heroku, and how ease-of-deployment and the developer experience really drove adoption of that platform.

OK, so generating dynamic text is OK for an MVP, it would be nice if we at least had a UI and some options. You can use Webpack to bundle resources in your Workers, but I wanted this app to be as simple as possible, so I created a basic HTML page to capture some options, included my HTML as a string, and served it from the root of my Worker. The full code listing is on  Github.

const ui = '...basic html page...';

async function handleRequest(request) {

    let url = new URL(request.url);
    //Serve the UI
    if (url.pathname === "/" ) {
        let init = { "status" : 200 , "headers" : { 'Content-Type': 'text/html' } };
        return new Response(ui, init);
    }

    let phraseCount = Math.min(parseInt(url.searchParams.get("phrases") || 100), 10000);
    let newLine = Math.min(parseInt(url.searchParams.get("newline") || 0), 10000);

    let phraseArr = getPhrasesArr(phraseCount);
    if (newLine > 0) {
        phraseArr = breakLines(phraseArr, newLine);
    }
    return new Response(phraseArr.join(''));
}

The team is now unblocked. Development can continue. Here's the full version in action. You can play with it live at: https://www.bobrossloremipsum.com

Want to join a rocketship? I’m hiring in Austin and San Francisco

My first Internet experience was paying $30 for a prepaid card with 10 hour access over a 14.4k modem. First, it was bulletin boards and later IRC and the WWW. From my small seaside town in Australia, the Internet was a window into the wider world, but it was slooooooow. In a way, it didn’t matter. The world of opportunities the Internet opened up, from information to music, to socializing and ecommerce, who cared if it was slow? The utility of the Internet and Internet applications meant I would use them regardless of the experience.

Performance improved from the 90s, but in 2008 when I switched from Outlook downloading my Yahoo! email over IMAP to Gmail in the browser, it wasn’t because it was faster - it wasn’t - it was because features like search, backed up mail, and unlimited storage were too good to resist. The cloud computing power that Google could bring to bear on my mail meant I was happy to trade native performance for a browser-based one that wasn’t bad, but definitely not snappy.

Efforts like Electron have attempted to blend performance and utility by offering a host in the native windowing technology, which loads an HTML5 app. It’s not working. Some of the most popular Electron apps today are not snappy at all.

Recorded on Macbook 2013 with 8gb RAM

So how did we get here and where are we going? I think of applications during the period of 1980-2018 like this:

1. 1980-2000 Functionality and performance increased at a similar rate

2. 2000-2018 Functionality increased during the Internet age, but perceived performance degraded

I think we’re entering the next phase, whereby performance and the user experience will again track the rise in the utility of those apps. I predict we’ll go back to a chart like this:

To summarize, while the Internet and the “Cloud” brought a huge increase in functionality the performance of Internet Applications has been hampered by:

• Downloading interpreted code

• Over chatty protocols

• From origin servers far away from users

This has prevented Internet Applications achieving their potential of being both performant and functional. This is changing and I am defining this new era of applications as Internet Native Applications.

Internet Native Applications will combine the utility of Internet apps, but with the speed of local desktop apps. These apps will feel magical, as the functionality that was previously in some distant data center, will now feel like just an extension of the computer itself.

How will this happen and what will be the drivers?

As huge Edge networks get closer to end-users, the perceived performance cost of not serving a request from the Edge and requiring a round-trip to a legacy cloud provider will increase. In a world where users will come to expect near-instant responses from Internet Native applications, a response not served from the Edge and requiring a trip to a centralized cloud-based origin will feel like a "cache miss".

In the same way systems programmers have to consider the impact of L1 vs L2 vs Main Memory access, so too will Internet Native application architects consider carefully each time an application requires a resource to be fetched or a computation to be run from a centralized data center, as opposed to the Edge. As more and more services are available <10ms from the end user, the cost of the new “cache miss” will increase. For comparison, a disk seek on an average desktop HDD costs around 10ms - the same time it takes to get a request to Edge, so Edge network requests will feel local - requests to far flung centralized data centers will be noticeably slow.

APIs, storage, and eventually even data-intensive tasks will be processed on the Edge. To the user, it will feel like this magical functionality is just an extension of their computer. As network compute nodes push further and further towards users, from Internet Exchange Points (IXs), to ISPs and even to cell towers, it will indeed be close to the truth.

Near instant

The new "cache miss"

Ever since the web emerged as the ultimate app distribution platform, there have been attempts to embed runtimes in browsers. Java Applets, ActiveX and Flash to name a few. Java probably made the most headway, but was plagued by write-once-debug-everywhere issues and installation friction.

WASM is gaining momentum and now ships in all major browsers. It's still an MVP, but with wide support and promising early performance testing, expect more and more apps to take advantage of WASM. It's early days  –  WASM can't interact with the DOM yet, but that is coming too. The debate is ongoing, but I believe WASM will enable user interaction with UI elements in the browser to get much closer to the “native” speed of the past.

TCP, conceived in 1981, can no longer meet the needs of the highest performing Internet applications. Dropped packets on mobile networks cause back-off and newer protocols handle congestion control better.

QUIC, now under the auspices of the IETF and starting to see Internet-facing server implementations, will underpin the connection of Internet Native applications to their nearest network compute node, mostly using an efficient, multiplexed HTTP/2 connection.

HTTPS

QUIC

With the Edge now a general-compute platform – more and more services will move there, driving up the percentage of requests that can be fulfilled within 10ms. Legacy cloud providers will continue to provide services like like AI/ML training, data pipelines and "big data" applications for some time, but many services will move "up the stack", to be closer to the user.

Source: https://github.com/google/go-cloud

CIOs woke up years ago to the risk of vendor lock-in and have defended against it in a variety of forms such as hybrid clouds, open-source, and container orchestration to name a few. Google launched another attempt to further commoditize cloud services with its launch of go/cloud. It provides a generalizable way for application architects to define cloud resources in a non-vendor specific way.

I believe Internet Native applications will increasingly define their cloud dependencies, e.g., storage, as pluggable implementation details, and deploy policies on the edge to route according to latency, cost, privacy and other domain-specific criteria.

No single technology defines Internet Native Applications. However, I believe the combination of:

• A rapidly increasing percentage of requests serviced directly from the Edge under 10ms

• Near-native speed code on the browser, powered by WebAssembly

• Improved Internet protocols like QUIC and HTTP/2

Will usher in a new era of performance for Internet-based applications. I believe the difference in user experience will be so significant, that it will bring about a fundamental shift in the way we architect the applications of tomorrow  –  Internet Native Applications  –  and Engineers, Architects and CIOs need to start planning for this shift now.

Do you remember people asking if “you have the Internet on your computer?” when people didn’t really understand what the Internet was? Internet Native applications will finally make it irrelevant  –  you won’t be able to tell the difference.

Want to work on technology powering the next era? I’m hiring for Cloudflare in San Francisco and Austin.

console.log in your Worker goes straight to the console, just as if you were debugging locally! Furthermore, errors and even log lines come complete with call-site info, so you click and navigate straight to the relevant line.In this blog post I’m going to show a small and powerful technique I use to make debugging serverless apps simple and quick.

There is a comprehensive guide to common debugging approaches and I'm going to focus on returning debug information in a header. This is a great tip and one that I use to capture debug information when I'm using curl or Postman, or integration tests. It was a little finicky to get right the first time, so let me save you some trouble.

If you've followed part 1 or part 2 of my Workers series, you'll know I'm using Typescript, but the approach would equally apply to Javascript. In the rest of this example, I’ll be using the routing framework I created in part 2.

I want my Worker to return debugging information whenever:

• An X-Debug header is present or

• a ?debug query parameter is present.

Exercise for the reader: You may also like to require a shared secret key (so that you control who can enable debugging information) and pass a log level.

I'd like my debug info to be the same that I'd see in the Workers IDE. That is, all the log lines and any exception info from the execution of my Worker.

Logging is orthogonal to the main request flow, so let's try keep it abstracted. Different frameworks use different terms for this abstraction. I’ll use the term interceptor.

Let's define an interceptor as something that runs pre and/or post the main request flow.

/**
 * Intercepts requests before handlers and responses after handlers
 */
export interface IInterceptor {
  preProcess(req: RequestContextBase): void;
  postProcess(req: RequestContextBase, res: Response): void;
}

And then run pre and post processing before and after the handler has executed.

public async handle(request: Request): Promise<Response> {
	this.preProcess(req);
	const handler = this.route(req);
	const res = await handler.handle(req);
	this.postProcess(req, res);
	return res;
}

private preProcess(req: RequestContextBase) {
	for (const interceptor of this.interceptors) {
	  interceptor.preProcess(req);
	}
}

private postProcess(req: RequestContextBase, res: Response) {
	for (const interceptor of this.interceptors) {
	  interceptor.postProcess(req, res);
	}
}

OK, so with a generalized pattern to execute code before and after a request, let's add our first Interceptor:

First we'll need a logger. This logger just redirects to console, but also keeps track of the log lines so the interceptor can retrieve them later.

export class Logger implements ILogger {
  public logLines: string[] = [];

  public debug(logLine: string): void {
    this.log(`DEBUG: ${logLine}`);
  }

  public info(logLine: string): void {
    this.log(`INFO: ${logLine}`);
  }

  public warn(logLine: string): void {
    this.log(`WARN: ${logLine}`);
  }

  public error(logLine: string): void {
    this.log(`ERROR: ${logLine}`);
  }

  public getLines(): string[] {
    return this.logLines;
  }

  public clear(): void {
    this.logLines = [];
  }

  private log(logLine: string): void {
    // tslint:disable-next-line:no-console
    console.log(logLine);
    this.logLines.push(logLine);
  }
}

The LogInterceptor is simple enough in post processing, if it detects the X-Debug header or debug query param, it adds all the log lines to the X-Debug response header as a URL-encoded string.

const logger = new Logger();

export class LogInterceptor implements IInterceptor {
  public preProcess(req: RequestContextBase) {
    return;
  }

  public postProcess(req: RequestContextBase, res: Response) {
    logger.debug('Evaluating request for logging');
    const debugHeader = 'X-Debug';
    if (
      req.url.searchParams.get('debug') !== 'true' &&
      req.request.headers.get(debugHeader) !== 'true'
    ) {
      return;
    }
    logger.debug('Executing log interceptor');
    const lines = logger.getLines();
    const logStr = encodeURIComponent(lines.join('\n'));

    logger.debug(`Adding to ${debugHeader} header ${logStr.length} chars`);
    res.headers.append(debugHeader, logStr);
  }
}

Now it's up to the client to display.

urldecode isn't native on most operating systems. There are Perl and Python implementations, but here's a Bash only function:

$ urldecode() { : "${*//+/ }"; echo -e "${_//%/\\x}"; }

Source: StackOverflow

Using that, we can call curl, extract the headers, grep for our X-Debug header and then invoke the urldecode function.

$ urldecode `curl -sD - -o /dev/null https://cryptoserviceworker.com/api/all/spot/btc-usd -H "X-Debug:true" | grep x-debug`
x-debug: INFO: Handling: https://cryptoserviceworker.com/api/all/spot/btc-usd
DEBUG: No handlers, getting from factory
DEBUG: Found handler for /api/all/spot/btc-usd
DEBUG: ["spot","btc-usd"]
DEBUG: Getting spot from https://api.gdax.com/products/btc-usd/ticker
DEBUG: ["spot","btc-usd"]
DEBUG: Parsing spot...
INFO: GDAX response {"trade_id":45329353,"price":"6287.01000000","size":"0.03440000","bid":"6287","ask":"6287.01","volume":"9845.51680796","time":"2018-06-25T18:12:48.282000Z"}
INFO: Bitfinex response {"mid":"6283.45","bid":"6283.4","ask":"6283.5","last_price":"6283.5","low":"6068.5","high":"6341.0","volume":"28642.882017660013","timestamp":"1529950365.0694907"}
DEBUG: Evaluating request for logging
DEBUG: Executing log interceptor

Boom. Decoded debug info right there in the console. Ship it.

If you log stack traces in your worker with logger.error(e.stack), that will also format nicely:

$ urldecode `curl -sD - -o /dev/null https://cryptoserviceworker.com/api/all/spot/btc-usd -H "X-Debug:true" | grep x-debug`
x-debug: INFO: Handling: https://cryptoserviceworker.com/api/all/spot/btc-usd
ERROR: Error: boom
    at Router.<anonymous> (worker.js:118:35)
    at step (worker.js:32:23)
    at Object.next (worker.js:13:53)
    at worker.js:7:71
    at new Promise (<anonymous>)
    at __awaiter (worker.js:3:12)
    at Router.handle (worker.js:111:16)
    at worker.js:48:42
    at step (worker.js:32:23)
    at Object.next (worker.js:13:53)
DEBUG: Evaluating request for logging
DEBUG: Executing log interceptor

In this post we:

• Defined a pre- and post-processing framework using Interceptors

• Implemented a LogInterceptor to return logs generated as we were processing in the X-Debug header

• Decoded them in bash

May the logs be with you.

I'm going to build a mini HTTP request routing and handling framework, then use it to build a gateway to multiple cryptocurrency API providers. My point here is that in a single file, with no dependencies, you can quickly build pretty sophisticated logic and deploy fast and easily to the Edge. Furthermore, using modern Typescript with async/await and the rich type structure, you also write clean, async code.

OK, here we go...

My API will look like this:

OK, this is Typescript, I get interfaces and I'm going to use them. Here's my ultra-mini-http-routing framework definition:

export interface IRouter {
  route(req: RequestContextBase): IRouteHandler;
}

/**
 * A route
 */
export interface IRoute {
  match(req: RequestContextBase): IRouteHandler | null;
}

/**
 * Handles a request.
 */
export interface IRouteHandler {
  handle(req: RequestContextBase): Promise<Response>;
}

/**
 * Request with additional convenience properties
 */
export class RequestContextBase {
  public static fromString(str: string) {
    return new RequestContextBase(new Request(str));
  }

  public url: URL;
  constructor(public request: Request) {
    this.url = new URL(request.url);
  }
}

So basically all requests will go to IRouter. If it finds an IRoute that returns an IRouterHandler, then it will call that and pass in RequestContextBase, which is just the request with a parsed URL for convenience.

I stopped short of dependency injection, so here's the router implementation with 4 routes we've implemented (Ping, Race, All and Direct). Each route corresponds to one of the four operations I defined in the API above and returns the corresponding IRouteHandler.

export class Router implements IRouter {
  public routes: IRoute[];

  constructor() {
    this.routes = [
      new PingRoute(),
      new RaceRoute(),
      new AllRoute(),
      new DirectRoute(),
    ];
  }

  public async handle(request: Request): Promise<Response> {
    try {
      const req = new RequestContextBase(request);
      const handler = this.route(req);
      return handler.handle(req);
    } catch (e) {
      return new Response(undefined, {
        status: 500,
        statusText: `Error. ${e.message}`,
      });
    }
  }

  public route(req: RequestContextBase): IRouteHandler {
    const handler: IRouteHandler | null = this.match(req);
    if (handler) {
      logger.debug(`Found handler for ${req.url.pathname}`);
      return handler;
    }
    return new NotFoundHandler();
  }

  public match(req: RequestContextBase): IRouteHandler | null {
    for (const route of this.routes) {
      const handler = route.match(req);
      if (handler != null) {
        return handler;
      }
    }
    return null;
  }
}

You can see above I return a NotFoundHandler if we can't find a matching route. Its implementation is below. It's easy to see how 401, 405, 500 and all the common handlers could be implemented.

/**
 * 404 Not Found
 */
export class NotFoundHandler implements IRouteHandler {
  public async handle(req: RequestContextBase): Promise<Response> {
    return new Response(undefined, {
      status: 404,
      statusText: 'Unknown route',
    });
  }
}

Now let's start with Ping. The framework separates matching a route and handling the request. Firstly the route:

export class PingRoute implements IRoute {
  public match(req: RequestContextBase): IRouteHandler | null {
    if (req.request.method !== 'GET') {
      return new MethodNotAllowedHandler();
    }
    if (req.url.pathname.startsWith('/api/ping')) {
      return new PingRouteHandler();
    }
    return null;
  }
}

Simple enough, if the URL starts with /api/ping, handle the request with a PingRouteHandler

export class PingRouteHandler implements IRouteHandler {
  public async handle(req: RequestContextBase): Promise<Response> {
    const pong = 'pong;';
    const res = new Response(pong);
    logger.info(`Responding with ${pong} and ${res.status}`);
    return new Response(pong);
  }
}

So at this point, if you followed along with Part 1, you can do:

$ npm run upload
$ curl https://cryptoserviceworker.com/api/ping
pong

OK, next the AllHandler, this aggregates the responses. Firstly the route matcher:

export class AllRoute implements IRoute {
  public match(req: RequestContextBase): IRouteHandler | null {
    if (req.url.pathname.startsWith('/api/all/')) {
      return new AllHandler();
    }
    return null;
  }
}

And if the route matches, we'll handle it by farming off the requests to our downstream handlers:

export class AllHandler implements IRouteHandler {
  constructor(private readonly handlers: IRouteHandler[] = []) {
    if (handlers.length === 0) {
      const factory = new HandlerFactory();
      logger.debug('No handlers, getting from factory');
      this.handlers = factory.getProviderHandlers();
    }
  }

  public async handle(req: RequestContextBase): Promise<Response> {
    const responses = await Promise.all(
      this.handlers.map(async h => h.handle(req))
    );
    const jsonArr = await Promise.all(responses.map(async r => r.json()));
    return new Response(JSON.stringify(jsonArr));
  }
}

I'm cheating a bit here because I haven't shown you the code for HandlerFactory or the implementation of handle for each one. You can look up the full source here.

Take a moment here to appreciate just what's happening. You're writing very expressive async code that in a few lines, is able to multiplex a request to multiple endpoints and aggregate the results. Furthermore, it's running in a sandboxed environment in a data center very close to your end user. Edge-side code is a game changer.

Let's see it in action.

$ curl https://cryptoserviceworker.com/api/all/spot/btc-usd
[  
   {  
      "symbol":"btc-usd",
      "price":"6609.06000000",
      "utcTime":"2018-06-20T05:26:19.512000Z",
      "provider":"gdax"
   },
   {  
      "symbol":"btc-usd",
      "price":"6600.7",
      "utcTime":"2018-06-20T05:26:22.284Z",
      "provider":"bitfinex"
   }
]

Cool, OK, who's fastest? First, the route handler:

export class RaceRoute implements IRoute {
  public match(req: RequestContextBase): IRouteHandler | null {
    if (req.url.pathname.startsWith('/api/race/')) {
      return new RaceHandler();
    }
    return null;
  }
}

And the handler. Basically just using Promise.race to pick the winner

export class RaceHandler implements IRouteHandler {
  constructor(private readonly handlers: IRouteHandler[] = []) {
    const factory = new HandlerFactory();
    this.handlers = factory.getProviderHandlers();
  }

  public handle(req: RequestContextBase): Promise<Response> {
    return this.race(req, this.handlers);
  }

  public async race(
    req: RequestContextBase,
    responders: IRouteHandler[]
  ): Promise<Response> {
    const arr = responders.map(r => r.handle(req));
    return Promise.race(arr);
  }
}

So who's fastest? Tonight it's gdax.

curl https://cryptoserviceworker.com/api/race/spot/btc-usd
{  
   "symbol":"btc-usd",
   "price":"6607.15000000",
   "utcTime":"2018-06-20T05:33:16.074000Z",
   "provider":"gdax"
}

Using Typescript+Workers, in < 500 lines of code, we were able to

• Define an interface for a mini HTTP routing and handling framework

• Implement a basic implementation of that framework

• Build Routes and Handlers to provide Ping, All, Race and Direct handlers

• Deploy it to 160+ data centers with npm run upload

Stay tuned for more, and PRs welcome, particularly for more providers.

If you have a worker you'd like to share, or want to check out workers from other Cloudflare users, visit the “Recipe Exchange” in the Workers section of the Cloudflare Community Forum.

My environment looks like this:

• macOS High Sierra

• node v8.11.3

• npm v5.6.0

• Webstorm v2018.1.3

You'll also need a Cloudflare domain and to activate Workers on it.

I'll be using cryptoserviceworker.com

I'll also use Yeoman to build our initial scaffolding. Install it with npm install yo -g

Let's start with a minimal node app with a "hello world" class and a test.

mkdir cryptoserviceworker && cd cryptoserviceworker
npm install generator-node-typescript -g
yo node-typescript

That generator creates the following directory structure:

drwxr-xr-x   16 steve  staff     512 Jun 18 20:40 .
drwxr-xr-x   10 steve  staff     320 Jun 18 20:35 ..
-rw-r--r--    1 steve  staff     197 Jun 18 20:40 .editorconfig
-rw-r--r--    1 steve  staff      96 Jun 18 20:40 .gitignore
-rw-r--r--    1 steve  staff     147 Jun 18 20:40 .npmignore
-rw-r--r--    1 steve  staff     267 Jun 18 20:40 .travis.yml
drwxr-xr-x    5 steve  staff     160 Jun 18 20:40 .vscode
-rw-r--r--    1 steve  staff    1066 Jun 18 20:40 LICENSE
-rw-r--r--    1 steve  staff    2071 Jun 18 20:40 README.md
drwxr-xr-x    4 steve  staff     128 Jun 18 20:40 __tests__
drwxr-xr-x  479 steve  staff   15328 Jun 18 20:40 node_modules
-rw-r--r--    1 steve  staff  244624 Jun 18 20:40 package-lock.json
-rw-r--r--    1 steve  staff    1506 Jun 18 20:40 package.json
drwxr-xr-x    4 steve  staff     128 Jun 18 20:40 src
-rw-r--r--    1 steve  staff     454 Jun 18 20:40 tsconfig.json
-rw-r--r--    1 steve  staff      73 Jun 18 20:40 tslint.json

It includes default settings, a task runner, an initial Typescript config and more. We won't use all of it, but it's a good starting point.

If we take a look at the contents of src/greeter.ts, we'll see it's a very Typescript implementation of hello world.

$ cat greeter.ts 
export class Greeter {
  private greeting: string;

  constructor(message: string) {
    this.greeting = message;
  }

  public greet(): string {
    return `Bonjour, ${this.greeting}!`;
  }
}

Because Yeoman has set up our test infrastructure, we should be able exercise the code using the greeter test in __tests__/greeter-spec.ts

import { Greeter } from '../src/greeter';

test('Should greet with message', () => {
  const greeter = new Greeter('friend');
  expect(greeter.greet()).toBe('Bonjour, friend!');
});

This generator uses jest. It's installed locally, but let's install it globally for convenience and run it!

npm install jest -g
jest
 PASS  __tests__/greeter-spec.ts
 PASS  __tests__/index-spec.ts

Test Suites: 2 passed, 2 total
Tests:       2 passed, 2 total
Snapshots:   0 total
Time:        1.867s
Ran all test suites.

OK, so we have a testable Typescript template. Let's fire up Webstorm and write some code!

A hello world implementation in Typescript might look something like this:

Webstorm doesn't like it as you can see from the red error highlights. Even though Request and Response are part of the Service Worker API and will be available to us in the V8 runtime, Typescript doesn't know about them yet. node-fetch provides an implementation for node, so let’s install that.

npm install node-fetch
npm install @types/node-fetch

That made Webstorm happier. It’s been able to locate the type definitions.

Now let's write a test. Create a new file tests/worker-spec.ts:

import { Request } from "node-fetch";
import { Worker } from "../src/worker";

test('Should say hello', () => {

  const worker = new Worker();
  const request = new Request("https://cryptoserviceworker.com/");
  const response = worker.handle(request);
  expect(response.status).toEqual(200);
  expect(response.body).toEqual("Hello, world!");
});

And delete the other files and tests so we're just working worker.ts and worker-spect.ts

Run jest

 PASS  __tests__/worker-spec.ts
 PASS  __tests__/worker-spec.js

Test Suites: 2 passed, 2 total
Tests:       2 passed, 2 total
Snapshots:   0 total
Time:        1.213s, estimated 2s

OK, so our test passed, but notice it ran both the Typescript and the Javascript? Let's restrict to just Typescript. Go into package.json, locate jest and change

"testRegex": "(/__tests__/.*|\\.(test|spec))\\.(ts|js)$", to"testRegex": "(/__tests__/.*)\\-spec.ts$"

Run it again:

jest
 PASS  __tests__/worker-spec.ts
  ✓ Should say hello (8ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        1.123s, estimated 2s
Ran all test suites.

Better. OK, ship it!

Let's take a look at src/worker.js to see how our Typescript transpiled.

"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
const node_fetch_1 = require("node-fetch");
class Worker {
    handle(request) {
        return new node_fetch_1.Response('Hello, world!');
    }
}
exports.Worker = Worker;

Actually, let's try it in the Cloudflare Workers IDE and try it for real. Go to your dashboard, click the Workers icon and then "Launch Editor"

First things first, check the canonical Hello World implementation works.

Awesome, now let's replace it with our "transpiled from Typescript" version:

Fail. OK, so the out of the box "transpiled from typescript" is not going to work. Let's make the changes necessary to get it run manually, then incorporate that into the build process.

Error #1: Uncaught ReferenceError: exports is not defined at line 2That's easy enough, let's add var exports = {}. Update Preview.

Error #2: Uncaught ReferenceError: require is not defined at line 4

True, we're running in V8 on the Cloudflare Edge and the only code is what we uploaded. There are no "node_modules" to include. Plus, that line was only for dev anyway. Remove it. Update Preview.

Error #3: No event handlers were registered. This script does nothing.

Right, we need to invoke the code. Let's add a snippet to the top of the file to actually invoke our worker.

addEventListener('fetch', event => {
  let worker = new exports.Worker();
  event.respondWith(worker.handle(event.request));
})

Error #4: Uncaught ReferenceError: node_fetch_1 is not defined

Right, we removed that because Response is a native object when it runs in the context of a worker. So remove the node_fetch_1 prefix.

Error #5: exports.__esModule = true does nothing

So let's remove that.

Success!!

OK, so with some massaging, we got a Worker transpiled from Typescript to execute. We:

• Added a line to create an exports object

• Removed the dev dependency on "node_fetch"

• Removed the exports.__esModule = true line

Let's add that to our build process so we can have "Worker-ready" Javascript every time we make a change to our Typescript.

I'm going to use Grunt to automate that. Here's my new worker.ts

// --BEGIN PREAMBLE--
/// //Invoke worker
/// var exports = {};
/// addEventListener('fetch', event => {
///   event.respondWith(fetchAndApply(event.request))
/// });
///
/// async function fetchAndApply(request) {
///   let worker = new exports.Worker();
///   return worker.handle(request);
/// }
// --END PREAMBLE--

// --BEGIN COMMENT--
// mock the methods and objects that will be available in the browser
import { Request, Response } from 'node-fetch';
// --END COMMENT--
export class Worker {
  public handle(request: Request) {
    return new Response("Hello, world!")
  }
}

I want to uncomment the preamble to invoke our script, comment out the dev dependencies and remove the __esmodule line. Let's install Grunt, a text-replace module and create a Gruntfile.js

npm install grunt-cli -g
npm install grunt --save-dev
npm install grunt-replace --save-dev
touch Gruntfile.js

My Gruntfile.js looks like this

module.exports = function (grunt) {

  grunt.loadNpmTasks('grunt-replace');
  grunt.initConfig({
    replace: {
      comments: {
        options: {
          patterns: [
            {
              /* Comment imports for node during dev */
              match: /--BEGIN COMMENT--[\s\S]*?--END COMMENT--/g,
              replacement: 'Dev environment code block removed by build'
            },
            {
              /* Uncomment preamble for production to process the request */
              match: /\/\/\//mg,
              replacement: ''
            }
          ]
        },
        files: [
          { expand: true, flatten: true, src: ['src/worker.ts'], dest: 'build/' }
        ]
      },
      exports: {
        //remove the exports line that typescript includes without an option to
        //suppress, but is not in the v8 env that workers run in.
        options: {
          patterns: [
            {
              match: /exports.__esModule = true;/g,
              replacement: "// exports line commented by build"
            }
          ]
        },
        files: [
          { expand: true, flatten: true, src: ['build/worker.js'], dest: 'build/' }
        ]
      }
    }
  });

  grunt.registerTask('prepare-typescript', 'replace:comments');
  grunt.registerTask('fix-export', 'replace:exports');
};

There are two tasks. The first is the comment/uncomment step that we want before our Typescript is transpiled.

The second is to remove the exports.__esmodule = true line

$ grunt prepare-typescript
Running "replace:comments" (replace) task
>> 11 replacements in 1 file.

Done.

If we open build/worker.ts, we see this:

// --BEGIN PREAMBLE--
 //Invoke worker
 var exports = {};
 addEventListener('fetch', event => {
   event.respondWith(fetchAndApply(event.request))
 });

 async function fetchAndApply(request) {
   let worker = new exports.Worker();
   return worker.handle(request);
 }
// --END PREAMBLE--

// Dev environment code block removed by build
export class Worker {
  public handle(request: Request) {
    return new Response("Hello, world!")
  }
}

Opening build/worker.js you'll see a whole lot of code generated for handling async functions. That's because we're using the async keyword in the preamble.

"use strict";
var __awaiter = (this && this.__awaiter) || function (thisArg, _arguments, P, generator) {
    return new (P || (P = Promise))(function (resolve, reject) {
        function fulfilled(value) { try { step(generator.next(value)); } catch (e) { reject(e); } }
        function rejected(value) { try { step(generator["throw"](value)); } catch (e) { reject(e); } }
        function step(result) { result.done ? resolve(result.value) : new P(function (resolve) { resolve(result.value); }).then(fulfilled, rejected); }
        step((generator = generator.apply(thisArg, _arguments || [])).next());
    });
};
var __generator = (this && this.__generator) || function (thisArg, body) {
    var _ = { label: 0, sent: function() { if (t[0] & 1) throw t[1]; return t[1]; }, trys: [], ops: [] }, f, y, t, g;
    return g = { next: verb(0), "throw": verb(1), "return": verb(2) }, typeof Symbol === "function" && (g[Symbol.iterator] = function() { return this; }), g;
    function verb(n) { return function (v) { return step([n, v]); }; }
    function step(op) {
        if (f) throw new TypeError("Generator is already executing.");
        while (_) try {
            if (f = 1, y && (t = y[op[0] & 2 ? "return" : op[0] ? "throw" : "next"]) && !(t = t.call(y, op[1])).done) return t;
            if (y = 0, t) op = [0, t.value];
            switch (op[0]) {
                case 0: case 1: t = op; break;
                case 4: _.label++; return { value: op[1], done: false };
                case 5: _.label++; y = op[1]; op = [0]; continue;
                case 7: op = _.ops.pop(); _.trys.pop(); continue;
                default:
                    if (!(t = _.trys, t = t.length > 0 && t[t.length - 1]) && (op[0] === 6 || op[0] === 2)) { _ = 0; continue; }
                    if (op[0] === 3 && (!t || (op[1] > t[0] && op[1] < t[3]))) { _.label = op[1]; break; }
                    if (op[0] === 6 && _.label < t[1]) { _.label = t[1]; t = op; break; }
                    if (t && _.label < t[2]) { _.label = t[2]; _.ops.push(op); break; }
                    if (t[2]) _.ops.pop();
                    _.trys.pop(); continue;
            }
            op = body.call(thisArg, _);
        } catch (e) { op = [6, e]; y = 0; } finally { f = t = 0; }
        if (op[0] & 5) throw op[1]; return { value: op[0] ? op[1] : void 0, done: true };
    }
};
exports.__esModule = true;
// --BEGIN PREAMBLE--
//Invoke worker
var exports = {};
addEventListener('fetch', function (event) {
    event.respondWith(fetchAndApply(event.request));
});
function fetchAndApply(request) {
    return __awaiter(this, void 0, void 0, function () {
        var worker;
        return __generator(this, function (_a) {
            worker = new exports.Worker();
            return [2 /*return*/, worker.handle(request)];
        });
    });
}
// --END PREAMBLE--
// Dev environment code block removed by build
var Worker = /** @class */ (function () {
    function Worker() {
    }
    Worker.prototype.handle = function (request) {
        return new Response("Hello, world!");
    };
    return Worker;
}());
exports.Worker = Worker;

Now let's remove that exports.__esModule = true line.

grunt fix-export

and now we'll see instead in the worker.js // exports line commented by build.

I just want to run npm run build and get Worker-friendly Javascript. Let's modify package.json to do just that. Change

"build": "tsc --pretty" to "build": "grunt prepare-typescript && tsc build/*.ts --pretty --skipLibCheck; grunt fix-export",

And run it.

npm run build will result in

"use strict";
var __awaiter = (this && this.__awaiter) || function (thisArg, _arguments, P, generator) {
    return new (P || (P = Promise))(function (resolve, reject) {
        function fulfilled(value) { try { step(generator.next(value)); } catch (e) { reject(e); } }
        function rejected(value) { try { step(generator["throw"](value)); } catch (e) { reject(e); } }
        function step(result) { result.done ? resolve(result.value) : new P(function (resolve) { resolve(result.value); }).then(fulfilled, rejected); }
        step((generator = generator.apply(thisArg, _arguments || [])).next());
    });
};
var __generator = (this && this.__generator) || function (thisArg, body) {
    var _ = { label: 0, sent: function() { if (t[0] & 1) throw t[1]; return t[1]; }, trys: [], ops: [] }, f, y, t, g;
    return g = { next: verb(0), "throw": verb(1), "return": verb(2) }, typeof Symbol === "function" && (g[Symbol.iterator] = function() { return this; }), g;
    function verb(n) { return function (v) { return step([n, v]); }; }
    function step(op) {
        if (f) throw new TypeError("Generator is already executing.");
        while (_) try {
            if (f = 1, y && (t = y[op[0] & 2 ? "return" : op[0] ? "throw" : "next"]) && !(t = t.call(y, op[1])).done) return t;
            if (y = 0, t) op = [0, t.value];
            switch (op[0]) {
                case 0: case 1: t = op; break;
                case 4: _.label++; return { value: op[1], done: false };
                case 5: _.label++; y = op[1]; op = [0]; continue;
                case 7: op = _.ops.pop(); _.trys.pop(); continue;
                default:
                    if (!(t = _.trys, t = t.length > 0 && t[t.length - 1]) && (op[0] === 6 || op[0] === 2)) { _ = 0; continue; }
                    if (op[0] === 3 && (!t || (op[1] > t[0] && op[1] < t[3]))) { _.label = op[1]; break; }
                    if (op[0] === 6 && _.label < t[1]) { _.label = t[1]; t = op; break; }
                    if (t && _.label < t[2]) { _.label = t[2]; _.ops.push(op); break; }
                    if (t[2]) _.ops.pop();
                    _.trys.pop(); continue;
            }
            op = body.call(thisArg, _);
        } catch (e) { op = [6, e]; y = 0; } finally { f = t = 0; }
        if (op[0] & 5) throw op[1]; return { value: op[0] ? op[1] : void 0, done: true };
    }
};
// exports line commented by build
// --BEGIN PREAMBLE--
//Invoke worker
var exports = {};
addEventListener('fetch', function (event) {
    event.respondWith(fetchAndApply(event.request));
});
function fetchAndApply(request) {
    return __awaiter(this, void 0, void 0, function () {
        var worker;
        return __generator(this, function (_a) {
            worker = new exports.Worker();
            return [2 /*return*/, worker.handle(request)];
        });
    });
}
// --END PREAMBLE--
// Dev environment code block removed by build
var Worker = /** @class */ (function () {
    function Worker() {
    }
    Worker.prototype.handle = function (request) {
        return new Response('Hello, world!');
    };
    return Worker;
}());
exports.Worker = Worker;

Paste that into the Workers IDE... works first time.

It's going to get old uploading from our IDE to the Web IDE every time we want to test a change and we're going to want to auto deploy from CI at some point. Thankfully there's Workers Configuration API, which makes it very simple to upload a Worker automatically:

curl -X PUT "https://api.cloudflare.com/client/v4/zones/:zone_id/workers/script" -H "X-Auth-Email:YOUR_CLOUDFLARE_EMAIL" -H "X-Auth-Key:ACCOUNT_AUTH_KEY" -H "Content-Type:application/javascript" --data-binary "@PATH_TO_YOUR_WORKER_SCRIPT"

OK, so we need our zone ID, Cloudflare email, auth key and path to the binary. I'm going to create Grunt task that uses the dotenv package to load config from a .env file or environment variables.

Create a .env file that looks like this:

CF_WORKER_ZONE_ID=xxxxxxxxxxxxxxxxxxx
CF_WORKER_EMAIL=steve@example.com
CF_WORKER_AUTH_KEY=xxxxxxxxxxxxxxxxxx
CF_WORKER_PATH=build/worker.js

To locate your zone ID and auth key, go to the dashboard, select your zone and click the "Overview" icon.

The zone ID is right there, then click "Get API key" and choose the "Global API Key" to get the Auth Key.

Fill out your .env with those values and then add the following to your Gruntfile which will:

• Read your config

• Upload to Cloudflare

• Parse any success or error messages.

grunt.registerTask('upload-worker', 'Uploads workers to Cloudflare', function(path) {

    require('dotenv').config();
    const fs = require('fs');
    const log = console;

    const done = this.async();
    const conf = readConfig();
    path = path || grunt.option('path') || process.env.CF_WORKER_PATH;
    if (!path) {
      fail("path is required");
    }
    if (!fs.existsSync(path)) {
      fail(`path not found ${path}`);
    }

    let script = fs.readFileSync(path);
    log.info("Uploading...");
    let url = `https://api.cloudflare.com/client/v4/zones/${conf.zoneId}/workers/script`;
    let options = {
      url: url,
      method: 'PUT',
      headers: {
        'Content-Type': 'application/javascript'
      },
      body: script
    };
    invokeApi(options, conf, done);
  });

  function invokeApi(options, conf, done) {

    // Add authentication to the request
    options.headers = options.headers || {};
    Object.assign(options.headers, {
      'X-Auth-Email': conf.email,
      'X-Auth-Key': conf.apiKey,
    });

    request(options, function(error, response) {
      try {
        if (error) {
          log.error(error);
          fail(`API failure ${response.statusCode} error: ${error}`);
          done();
          return;
        }
        let body = JSON.parse(response.body);
        if (body) {
          logResult(body);
        }
        done();
      } catch (e) {
        fail(`Unhandled error. ${e}`);
        done();
      }
    });
  }

  function logResult(body) {
    body.success ? log.error("Status: Success") : log.error("Status: Failed");
    let errors = body.errors || [];
    if (errors) {
      log.info(` Errors: ${errors.length}`);
      for (let e of errors) {
        log.error(` Code: ${e.code} Message: ${e.message}`);
      }
    }
    let messages = body.messages || [];
    if (messages) {
      log.info(` Messages ${messages.length}`);
      for (let msg of messages) {
        log.info(` ${msg}`);
      }
    }
    let result = body.result;
    log.info(" Result");
    log.info(` ${JSON.stringify(result, null, 2)}`);
  }

  function readConfig() {
    let zoneId = grunt.option('zoneId') || process.env.CF_WORKER_ZONE_ID;
    let email = grunt.option('email') || process.env.CF_WORKER_EMAIL;
    let apiKey = grunt.option('apiKey') || process.env.CF_WORKER_AUTH_KEY;

    log.debug("zoneID: " + zoneId);
    log.debug("email: " + email);
    log.debug("apiKey: " + "*".repeat(apiKey.length));

    if (!zoneId || !email || !apiKey) {
      fail("zone id, cloudflare email and api key are required");
    }
    return {
      zoneId: zoneId,
      email: email,
      apiKey: apiKey
    }
  }

  function fail(message) {
    grunt.fail.fatal(message, TASK_FAILED);
  }

Finally, let's add a new task to package.json so we can just npm run upload any time we update our Worker.

"upload": "grunt upload-worker"

npm run upload-worker

Running "upload-worker" task
zoneID: **************
email: steve@example.com
apiKey: *************************************
Uploading...
Status: Success
 Errors: 0
 Messages 0
 Result
 {
  "script"...
 }

Voila! Script uploaded. OK, so if it's uploaded, we can call call it remotely:

$ curl https://cryptoserviceworker.com/hello

Hmmm... nothing. Ah, we haven't actually configured Workers to route any requests to our Worker. You can do this via the API, but since it's a one off, I'll do it in the web IDE.

And try again:

$ curl https://cryptoserviceworker.com/hello
Hello, world!

Success! OK, so to recap:

• We've bootstrapped a Typescript project using NodeJS and Webstorm

• Written a "Hello, World" worker in Typescript

• Setup build tasks to modify the code for Workers

• Automatically uploading to the Cloudflare edge with npm run upload

• ...

• Profit

If you have a worker you'd like to share, or want to check out workers from other Cloudflare users, visit the “Recipe Exchange” in the Workers section of the Cloudflare Community Forum.

Argo Tunnel exposes applications running on your local web server, on any network with an Internet connection, without adding DNS records or configuring a firewall or router. It just works.

Once I grokked this, the first thing that came to mind was that I could actually use one of my Raspberry Pi's sitting around to serve a website, without:

• A flaky DDNS running on my router

• Exposing my home network to the world

• A cloud VM

Ooooh... so exciting.

I'll assume you already have a Raspberry Pi with Raspbian on it.

Plug the Pi into your router. It should now have an IP address. Look that up in your router’s admin UI:

OK, that's promising. Let's connect to that IP using the default pi/raspberry credentials:

$ ssh 192.168.8.26 -l pi
pi@192.168.8.26's password: 

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sun Mar 18 23:24:11 2018 from stevens-air-2.lan
pi@raspberrypi:~ $ 

We're in!

Pro tip: quick way to figure it out which type you have is

pi@raspberrypi:~ $ cat /proc/cpuinfo | grep 'Revision' | awk '{print $3}' | sed 's/^1000//'
a22082

Then look up the value in the Raspbery Pi revision history. I have Raspberry Pi 3 Model B

OK, so we have a Pi connected to our router. Let's make 100% sure it can connect to the Internet.

pi@raspberrypi:~$ $ curl -I https://www.cloudflare.com
HTTP/2 200
date: Tue, 20 Mar 2018 22:54:20 GMT
content-type: text/html; charset=utf-8
set-cookie: __cfduid=dfb9c369ae12fe6eace48ed9b51aedbb01521586460; expires=Wed, 20-Mar-19 22:54:20 GMT; path=/; domain=.cloudflare.com; HttpOnly
x-powered-by: Express
cache-control: no-cache
x-xss-protection: 1; mode=block
strict-transport-security: max-age=15780000; includeSubDomains
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
served-in-seconds: 0.025
set-cookie: __cflb=3128081942; path=/; expires=Wed, 21-Mar-18 21:54:20 GMT
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 3febc2914beb7f06-SFO-DOG

That first line HTTP/2 200 is the OK status code, which is enough to tell us we can connect out to the Internet. Normally this wouldn't be particularly exciting, as it's allowing connections in that causes problems. That's the promise of Argo Tunnels however, it says on the tin we don't need to poke any firewall holes or configure any DNS. Big claim, let's test it.

Go to https://developers.cloudflare.com/argo-tunnel/downloads/ to get the url for the ARM build for your Pi. At the time of writing it was https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-linux-arm.tgz

$ wget https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-linux-arm.tgz
Resolving bin.equinox.io (bin.equinox.io)... 54.243.137.45, 107.22.233.132, 50.19.252.69, ...
Connecting to bin.equinox.io (bin.equinox.io)|54.243.137.45|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 5293773 (5.0M) [application/octet-stream]
Saving to: ‘cloudflared-stable-linux-arm.tgz’
...

Untar it

$ mkdir argo-tunnel
$ tar -xvzf cloudflared-stable-linux-arm.tgz -C ./argo-tunnel
cloudflared
$ cd argo-tunnel

Check you can execute it.

$ ./cloudflared --version
cloudflared version 2018.3.0 (built 2018-03-02-1820 UTC)

Looks OK. Now, we're hoping that the agent will magically connect from the Pi out to the nearest Cloudflare POP. We obviously want that to be secure. Furthermore, we're expecting that when a request comes inbound, it magically gets routed through Cloudflare's network and back to my Raspberry Pi.

Seems unlikely, but let’s have faith. Here is my mental model of what's happening:

So let's create that secure tunnel. I guess we need some sort of certificate or credentials...

$ ./cloudflared login

You'll see output in the command window similar to this:

A browser window should have opened at the following URL:

https://www.cloudflare.com/a/warp?callback=<some token>

If the browser failed to open, open it yourself and visit the URL above.

Our headless Pi doesn't have a web browser, so let's copy the url from the console into the browser on our host dev machine.

This part assumes you already have a domain on Cloudflare If you don't go to the setup guide to get started.

We're being asked which domain we want this tunnel to sit behind. I've chosen pacman.wiki. Click Authorize.

You should now see this back on your pi:

You have successfully logged in.
If you wish to copy your credentials to a server, they have been saved to:
/home/pi/.cloudflared/cert.pem

Aha! That answers how the tunnel gets secured. The agent has created a certificate and will use that to secure the connection back to Cloudflare. Now let's create the tunnel and serve some content!

$ cloudflared --hostname [hostname] --hello-world

hostname is a fully-qualified domain name under the domain you chose to Authorize for Argo Tunnels earlier. I'm going to use tunnel.pacman.wiki

$ ./cloudflared --hostname tunnel.pacman.wiki --hello-world
INFO[0002] Proxying tunnel requests to https://127.0.0.1:46727 
INFO[0000] Starting Hello World server at 127.0.0.1:53030 
INFO[0000] Starting metrics server                       addr="127.0.0.1:53031"
INFO[0005] Connected to LAX                             
INFO[0010] Connected to SFO-DOG                         
INFO[0012] Connected to LAX                             
INFO[0012] Connected to SFO-DOG  

Huh, interesting. So, we've connected to my nearest POP(s). I'm in the San Francisco Bay Area, so SJC and LAX seems reasonable. What now though? Surely that's not it? If I'm reading this right, I can go to my browser, enter https://tunnel.pacman.wiki and I'll get a hello world page... surely not.

And back on the Pi

INFO[0615] GET https://127.0.0.1:62627/ HTTP/1.1 CF-RAY=4067701b598e8184-LAX
INFO[0615] 200 OK  CF-RAY=4067701b598e8184-LAX

Mind. Blown. So what happened here exactly...

1. The agent on the Pi created a secure tunnel (a persistent http2 connection) back to the nearest Cloudflare Argo Tunnels server

2. The tunnel was secured with the certificate generated by the agent.

3. A request for https://tunnel.pacman.wiki went from my browser out through the Internet and was routed to the nearest Cloudflare datacenter

4. Cloudflare received the request, saw the domain was Cloudflare managed and saw a tunnel set up to that hostname

5. The request got routed over that http2 connection back to my Pi

I'm serving traffic over the Internet, from my Pi, with no ports opened on my home router. That is so cool.

If you're reading this, I've won my battle with the Cloudflare blog editing team about long form vs short form content :p

Serving hello world is great, but I want to expose a real web server. If you're like me, if you can find any vaguely relevant reason to use Rust, then you use Rust. If you're also like me, you want to try one of these async web servers the cool kids talk about on /r/rust like gotham. Let's do it.

First, install rust using rustup.

$ curl https://sh.rustup.rs -sSf | sh

When prompted, just hit enter

1) Proceed with installation (default)
2) Customize installation
3) Cancel installation
...
  stable installed - rustc 1.24.1 (d3ae9a9e0 2018-02-27)
...

OK, Rust is installed. Now clone Gotham and build the hello_world example:

$ git clone https://github.com/gotham-rs/gotham
$ cd gotham/examples/hello_world
$ cargo build

Pro tip: if cargo is not found, run source $HOME/.cargo/env. It will be automatic in future sessions.

As cargo does its magic, you can think to yourself about how it's a great package manager, how there really are a lot of dependencies and how OSS really is standing on the shoulders of giants of giants of giants of giants—eventually you'll have the example built.

...
Compiling gotham_examples_hello_world v0.0.0 (file:///home/pi/argo-tunnel/gotham/examples/hello_world)
    Finished dev [unoptimized + debuginfo] target(s) in 502.83 secs
    
$ cd ../../target/debug
$ ./gotham_examples_hello_world 
Listening for requests at http://127.0.0.1:7878

We have a rust web server listening on a local port. Let's connect the tunnel to that.

./cloudflared --hostname gotham.pacman.wiki http://127.0.0.1:7878

Type gotham.pacman.wiki into your web browser and you'll see those glorious words, "Hello, world".

OK, challenge accepted. Rust being fancy and modern is OK with Unicode. Let's serve some of that.

$ cd examples/hello_world/src/
$ nano src/main.rs 

Replace the hello world string:

Some((String::from("Hello World!").into_bytes(), mime::TEXT_PLAIN)),

with some Unicode and a content-type hint so the browser know how to render it:

Some((String::from("<html><head><meta http-equiv='Content-Type' content='text/html; charset=UTF-8'></head><body><marquee>Pᗣᗧ•••MᗣN</marquee></body></html>").into_bytes(), mime::TEXT_HTML)),

Build and run

$ cargo build
...
./gotham_examples_hello_world 
Listening for requests at http://127.0.0.1:7878

$ ./cloudflared --hostname gotham.pacman.wiki http://127.0.0.1:7878

And now we have some unicode served from our Pi at home over the Internet by a highly asynchronous web server written in a fast, safe, high-level language. Cool.

We should probably auto start both the agent and the web server on boot so they don't die when we end our ssh session.

$ sudo ./cloudflared service install
INFO[0000] Failed to copy user configuration. Before running the service, 
ensure that /etc/cloudflared contains two files, cert.pem and config.yml  
error="open cert.pem: no such file or directory"

Nice error! OK, the product team have helpfully documented what to put in that file here

$ sudo cp ~/.cloudflared/cert.pem /etc/cloudflared
$ sudo nano /etc/cloudflared/config.yml

#config.yml
hostname: gotham.pacman.wiki
url: http://127.0.0.1:7878

$ sudo ./cloudflared service install
INFO[0000] Using Systemd                                
ERRO[0000] systemctl: Created symlink from /etc/systemd/system/multi-user.target.wants/cloudflared.service to /etc/systemd/system/cloudflared.service.
INFO[0000] systemctl daemon-reload       

Copy the web server executable somewhere outside the gotham source tree so you can play around with the source code. I copied mine to /home/pi/argo-tunnel/server/bin/

nano /etc/rc.local

Add line: /home/pi/argo-tunnel/server/bin/gotham_examples_hello_world & just before exit 0

sudo reboot

On restart, ssh back in again and check both the agent and server are running.

$ sudo ps -aux | grep tunnel
root       501  0.1  0.2  37636  1976 ?        Sl   06:30   0:00 /home/pi/argo-tunnel/server/bin/gotham_examples_hello_world
root       977 15.7  1.4 801292 13972 ?        Ssl  06:30   0:01 /home/pi/argo-tunnel/cloudflared --config /etc/cloudflared/config.yml --origincert /etc/cloudflared/cert.pem --no-autoupdate

Profit.