Originally aired on May 23 @ 6:30 PM - 7:00 PM EDT
Cloudflare Platform Week: Developer Speaker Series
As part of Cloudflare's Platform Week, we're thrilled to feature an array of expert web dev speakers, developers, and educators here on Cloudflare TV.
We spent the last six months rewriting wrangler, the CLI for building and deploying Cloudflare Workers. Almost every single feature has been upgraded to be more powerful and user friendly, while still remaining backward compatible with the original version of wrangler. In this talk, we'll go through some of the best parts about the rewrite, and how it provides the foundation for all the things we want to build in the future.
Visit the Platform Week Hub for every announcement and CFTV episode — check back all week for more!
Hi, everyone. On the other side of the screen. My name is Sunil.
I'm a tech lead on the developer productivity team in the Workers log in Cloudflare and this week is Platform Week in Cloudflare.
We have a number of exciting announcements.
Today is just day two and we have already turned around a number of our products and made them so much bigger in scope.
The one that I want to talk to you about today is our CLI called Wrangler.
So Wrangler is the CLI for the Workers platform.
It helps you create Workers.
It helps you develop Workers.
It helps you bind it to other services inside Cloudflare so when you want to use a KV store or Durable Objects, Wrangler helps you do that and it helps you publish your Workers to production up to a website and a URL.
For some time last year we identified that we need to take a hard look at the developer experience around Wrangler itself, and we started work on rewriting it, not just in terms of the experience but even the entire codebase to be able to iterate quickly, ship quickly and closer to what our users actually expect.
We had to look at every command, every configuration really, and we did a rethinking of the experience behind it and we announced a beta in November.
People liked it then, but we did so much work since then to be fairly backward compatible.
In fact, we tried our best not to have any breaking applications at all, to be mostly backward compatible and just a nicer developer experience.
My story here is also personal.
I kind of I used to work in a bank and I didn't like it very much, which is why I used to use Cloudflare Workers in the evenings and weekends just to have fun.
And I liked it a lot, but the experience of Wrangler had a little to be desired.
I felt like it could be better.
I started talking to people inside Workers and they're all a very awesome bunch.
And at one point I was like, You know what? I really just want to work with the team on making this better.
So I joined them. And so over the last seven, eight months, maybe I've been working full time on this, not just me, my entire team, and we're very happy and proud that it's now generally available for everyone to use.
We recommend that you use it in production, you can use it today.
So instead of having a launch blog post, I thought I'd be very specific and talk about the top ten things that I like about Wrangler.
And it starts with the very it's it starts with the...
Just go full screen, I guess.
It starts with the onboarding experience. So previously you would have to use you would have to call this entire command npminstall @Ccoudflare/wrangler -global.
So installing it globally is a little annoying because it means that you can't use different versions of Wrangler per project.
Let's say that you have something you're using in one project and you just want to try out the new version with the new project.
You can't really do that because it's now installed globally.
Further, we actually had some feedback saying people who are always confused about having ad Cloudflare before and they would always forget it, including myself while I was working internally at Cloudflare.
So we fixed that.
It's now a much simpler npm install wrangler.
In fact, you can save it locally to your project by saying npm install wrangler.
Or you can just say save dev, which makes it a developer dependency and you can still install it globally if you want to use it.
And I think we can enhance the experience a little more, but this just is so much simpler, so much nicer, way more familiar, way more similar to the way other NPM packages are installed.
And that's nice.
Just the onboarding experience is nice. In fact, what's nice about this is that you don't even get to the onboarding for a single worker in a bit.
So you do that with Wrangler one. The other thing is that you would have to set up a configuration file, something called a wrangler.toml before you got started.
It involved you giving the name of it a type, which was a little weird because Webpack isn't really a type, but it meant something for us.
It meant that you could use Webpack to do a build, etc.
You would have to enter your account ID and your zone ID and these are some of these are very Cloudflare service specific.
And then what happened is we are now trying to encourage people to write their Workers in a format called modules, which is slightly different.
But to be able to do that, you need to have some more configuration which specifies that the format is a modules worker and an upload directory.
And of course, none of this really works without having, if you're trying to use modules, you might want to set up a build script or something else, and you have to change the type to JavaScript.
There's a lot of specific configuration and we changed all that in Wrangler 2, in Wrangler 2 you don't have to write any configuration before you get started.
We can just infer it because as you can imagine, a lot of this, we can just infer.
We know what your account ID is, when you log, we can automatically log you and we can figure out what your account ID is.
We...
As long as you point us to an entry point, we can actually statically detect whether it's a service worker format or a modules format.
There's so much that we can do for you out of the box so there's no mandatory configuration anymore.
You just can write a Worker and get going.
In fact, what I really like is that, not only do you not need configuration, but you don't even need to install Wrangler anymore, because we can actually fetch it from the cloud with NPX.
NPX is a utility that ships with NPM and Node.js, which is pretty much on 99.6% of users' machines.
So you can literally write a file saying index.js and say npx wrangler.index.js and it just works, which is just such a nice experience with your onboarding.
You can start working on your idea and you can do the configuration stuff later.
Another thing that we worked on is something called Wrangler Tail. A Wrangler tail is how you see logs for your Worker in production.
The requests you made, consult, log statements, everything.
Previously you would literally have to check out the Worker and install its dependencies and then run Wrangler tail inside it.
Now, you don't really need to do that anymore.
You don't even need to check out the repo.
You can just run in the terminal and fix Wrangler tail to the name of your Worker and it just works.
Of course, another way to do this is to just go into your dashboard, into your Cloudflare dashboard for a given Worker, and you can see logs right there as well, which is nice.
So now you have like four policy users who want to do a grep or something.
You can do it in the terminal. Otherwise you can just go to your dashboard.
There's no need to check out the actual repository, which is quite nice.
This.
As I mentioned, we don't really need a configuration to get started anymore, but that's not necessarily enough, right?
Like people do in modern JavaScript, in the ecosystem, there are some things that people use very commonly.
Stuff like TypeScript, stuff like NPM, and we'll get to that in a bit.
But and even when you use TypeScript, we need if you need to have installed the custom types for the Workers environment where some API is, we behave a little differently.
But there are APIs like Durable Objects that are very custom to the Workers environment, which are not available in every standards based runtime.
So we made Wrangler in it so much more powerful previously it would just output Wrangler file, but now if you pass it a name of a Worker, it asks you a number of questions as to, Hey, do you want to use TypeScript?
You want to just install package, start JSON and like the type things, it's like you can even pass it to flag saying why and it installs all of these for you by default.
It just spits out a Worker or a project for you. It even sets up Git, by the way, which is nice.
We just added that a few days ago.
So there's a single one liner to get started with full on project and you can start installing dependencies and so on.
Next, our number one ask from our developers was something called local mode.
To explain what this is, I should explain what happens when you run Wrangler on a Worker.
So you run Wrangler them when it says, Hey, open up localhost and you can open it and you can see the response is right there.
But that's not necessarily running on your own machine.
What we do is we actually package that Worker and send it up to the edge.
And it's not really far knowing how big Cloudflare's network is.
In fact, from what I understand, it's about 9 milliseconds away from me.
It might be pretty close to you, one of these days we'll bring it behind your washing machine.
But we upload it up there and it runs in an environment which is almost exactly the same as your production environment, which is great when you want to be certain of the code that you're writing, that it's running in exactly the kind of environment it will in production.
However, this can be a problem for a number of reasons.
For example, if you're hacking on a flight or your net connection isn't great, that means you can't develop on a Worker.
Just isn't great, really.
Or you want to run tests on something called an air gapped machine which can't make network calls.
I wouldn't work well either.
So instead, users, our users have been constantly asking us for something that we like calling local mode.
Can I just somehow run it all on my machine and then publish it to the edge?
Last year, someone named Brendan Cole, who I'm so happy to announce, will actually be joining our team officially in a couple of months, he made a fully fledged Cloudflare Workers simulator called Mini Flair.
Great project, and we loved it so much that Brendan actually came over and did an internship with us and not just did we bless it, but it's now officially a Cloudflare project and we are going to keep working on it and investing in it.
We announced it on the blog last year and it hit 2.0 earlier this year.
And now with dash dash local mode in Wrangler 2, it works seamlessly to provide a local dev environment for a worker with no other change to your configuration file or so on.
It just works and all the new features from Wrangler also just work with mini flair.
So that's pretty great. Local mode is now in Wrangler and that's pretty cool.
This is Wrangler tail, which I mentioned already.
Another thing that we learned, and it's not just that we learned it from our users and the community, we actually learned it from.
I learned it because I felt this way as well, which is that when Wrangler would give errors, some of the errors would come from the API which are very Cloudflare specific meanings or the configuration wouldn't be very well validated.
So we had a hard look at this and then we spent a whole bunch of time making them look much better.
So we now have intense, incredibly deep validation of all the values in your configuration, in your code.
And not just that we actually work hard on one, figuring out for the newer features how can we use older configuration and still make it work.
But also, we try to make it such that you can have copy paste messages that you can just insert into your configuration file and it'll just work, which is really nice because when I'm writing code, I have no need to understand the quirks of Wrangler.
I have no need to know what the motivation was of the Workers team.
I just want to write code and get along with it.
And it's so nice when the tools that I'm using not just help me identify the errors and warnings that I'm seeing, but also provide me a way forward.
Maybe what we should do, I think, is the next thing we should do is just automate this like we should just automatically edit your configuration for you and carry on.
I think that should be a good feature, but we're at a place where there's so much nicer and so much prettier to get the color coding so much better with errors now.
The next thing that I want to talk about is how we have way better debugging support.
So we actually did announce support for Chrome Dev tools last year. I think we did that in November and it's pretty great.
What it means is that you can use your regular chrome dev tools or edge and connect directly to a worker running on the edge in development mode.
And that's pretty cool.
That's kind of why, I'm not sure, I don't know who else does this.
I suppose somebody does, but we do a pretty good job of it, except the way to connect to it is a little annoying.
So what do you need to have done?
Is started Wrangler dev with an inspect flag and then you open Chrome inspect which is one special tab in your browser.
And then somewhere inside that you choose a thing where it says Cloudflare Workers and then you open the dev tools.
And the problem is that you might have missed a bunch of debugging messages before it has started.
You might come into across an error and now you need to shut down Wrangler dev because you forgot to give the inspect flag.
This is all not great.
So in Wrangler 2, it's one hotkey.
You don't need to pass any flag.
It buffers messages.
You never miss anything and you can just hit D and it opens dev tools again.
It works in both local mode, remote mode and this is just so much fun to use.
This is actually pretty nice.
It pops open up devtools for you and I wish I could have demoed something to you today, but I couldn't get it working in time.
The next thing that we want to do is make your VS code developer tools connect to this automatically.
So you'll be writing code and you'll hit Play and it starts a developer thing and we ask the developer tools which includes debugging, etc.
At some point we'll do breakpoints as well, just connect to the network.
So debugging and developer tools are so much better now.
By the way, you can see the other hotkeys that we support when we run Wrangler.
You can hit a hotkey and open the browser tab to the worker.
You can hit L to toggle between remote and local modes and of course want to just exit because control C or colon WQ is a is a 19th century thing.
We don't do that.
Awesome.
One of the very common tasks that we saw with people using Wrangler is. People end up used to set up to do some very common things.
They want to write that code as modules split it up into files and use imports and exports.
They want to be able to use third party dependencies from NPM or other registries, maybe from the GitHub registry.
It doesn't matter like from multiple from other registries and they won't use popular libraries like React, etc..
And for that to happen, you would have to install Webpack and maybe write yourself a custom Webpack configuration and maybe add a bunch of plugins.
We don't we don't want our users to spend time doing that.
So what we do is we just do what everyone else does, which is so now Wrangler supports a modern full fledged module system, much like node or den or any other runtime out there.
So you can use packages from NPM, you can literally run NPM, install, React, and it'll just work.
You can use TypeScript.
As I said, it just works out of the box.
In fact, we generate we can generate a config and install the Workers types for you.
We also have some special stuff where you can import text and data and volume files and even that works.
And that's something that I don't think other runtimes have a great story for yet, but tradeoffs.
But it works for us.
Like if you want to use volume in Cloudflare Workers, it's as simple as saying import of a module, so you don't really need Webpack anymore for the common stuff.
Of course, if you do want to do something custom, for example, let's say you want to do as well.
So it is a good example.
Be a great framework where it has a custom format for writing.
Of your components.
I think there are separate files.
We don't support that out of the box, but you can very much just use a custom build and you still have that function that if you want to do something custom super as a power user, you're welcome to do that.
But for the most common use cases that people use, Workers just works out of the box.
This is nice. The next thing I want to talk about is that I understand that rewrites are kind of scary, especially because we always talk about how a rewrite will solve all problems with the previous version.
And of course, they never sort of do, but we did our best effort.
What we did is we went through a lot of the open issues and some of the auto closed issues from one.x and we kind of just fixed most of them.
In fact, some of them were just fixed by the nature of us now using node instead of a rust binary for.
Building our stuff.
So now it works across multiple CPUs and operating system CPU architectures and operating systems.
I remember when the Apple M1 Macs came out, it was quite well, it just didn't work very well at the time.
So this now just works across basically nodes.
Usage matrix means that it just works with Wrangler multiple other things, stuff like using NPM modules, being able to run Wrangler dev locally.
I can't even show you the...
This is as much of the screenshot that fit on this page.
It's actually actually about twice this length, but you can find it in the repository if you want.
So the fact we basically went through as many issues as we could and there are still some and we will still work on it.
But that brings me to my absolute favorite, favorite favorite feature about Wrangler to.
But just that it's a commitment to improve. We love our users and customers.
We would be nowhere without them.
It's quite a capitalist thing to say, but no, we actually do.
We fundamentally love our users.
They give us validation for the things we do, especially with something as experimental and ambitious as the Workers platform and.
The thing we announced in November took some work to become pretty decent, but it took so much work to get this to be featured complete.
In fact, this is missing another month of work where the graph actually spiked some more.
It was the last month of work, of course, and one I would love for our users and community to know that well.
We think Wrangler is the primary developer interface for using the platform and we want them to know that we are investing our time and effort in it, not just for them really, but for ourselves.
Well, for me.
Well, our team uses actually uses Wrangler to build stuff and we don't like being irritated by the tools that we build.
We want them to be we want them to be great, not just good.
So this is a commitment to our community that we will continue working on this and making this a better experience.
And we hope that you come along with this for this journey with us, and I'm quite excited about that.
So those that's ten things I like about Wrangler many other things, but I just want to take this moment to thank some people, specifically the people we've worked with, Ashkan and James, of course, who are leading product and Ian, Pete, Cass, Jacob, we worked pretty nonstop for months and months to get it here and we plan on working on it for a while longer because it's we have a lot of plans ahead of us and we think that this is the right foundation for all the plans that we have.
So that's Wrangler 10.
No real messages, so... Thank you.
Thank you for listening to me. Talk about Wrangler.
Feel free to reach out to me at 3.1 on Twitter where I can show you and reach out to me here.
This is where I usually hang our earlier. This is where I usually hang.
Or you can add Cloudflare dev who's... The good people run this account, and I'm looking forward to seeing what all of you do with Wrangler.
I know I'm going to be trying a bunch of things, so let's stop sharing our screen and thank you.
I will see you all when I see you.
80.
We're About You, a fashion platform that has become the number one fashion platform in Europe in the Generation Y and Z.
It has been tremendously successful because we have built the technology stack from a commerce perspective, then decided to also make it available to leading fashion brands such as Marco Polo, Tom Tailor, the Founded and many other.
And that's how scale was born.
What we see in the market is that the attack vectors are becoming increasingly more scaled, distributed and complex as a whole.
We decided to bring on Cloudflare to ultimately have the best possible security tech stack in place to protect our brands and retailers.
We use the Cloudflare support management, rate limiting and WAF as an extra layer of protection for our customers by tackling the major cyber threats that we see in the market.
DDoS attacks, credential stuffing and scalping bots. What we see with a scalping bot here is that they're targeting high end products and then buying them up within a few seconds.
That leaves the customer dissatisfied.
They will turn away and purchase somewhere else the product and thereby we have lost a customer.
Generally, before it could take maybe up to half an hour for a security engineer to handle the DDoS attacks.
Now we are seeing that Cloudflare could help us to stop that in an automatic way.
Cloudflare helps us to bring the site performance to the best and ultimately therefore create even more revenue with our clients.
You run a successful business through your e-commerce platform.
Sales are at an all time high.
Costs are going down and all your projection charts are moving up into the right.
One morning you wake up and log into your science analytics platform to check on current sales and see that nothing is sold recently.
You type in your URL only to find that it is unable to load.
Unfortunately, your popularity may have made you a target of a DDoS or distributed denial of service attack, a malicious attempt to disrupt the normal functioning of your service.
There are people out there with extensive computer knowledge whose intentions are to breach or bypass Internet security.
They want nothing more than to disrupt the normal transactions of businesses like yours.
They do this by infecting computers and other electronic hardware with malicious software or malware.
Each infected device is called a bot.
Each one of these infected bots works together with other bots in order to create a disruptive network called a botnet.
Botnets are created for a lot of different reasons, but they all have the same objective.
Taking web resources like your website offline in order to deny your customers access.
Luckily, with Cloudflare, DDoS attacks can be mitigated and your site can stay online no matter the size, duration and complexity of the attack.
When DDoS attacks are aimed at your Internet property, instead of your server becoming deluged with malicious traffic, Cloudflare stands in between you and any attack traffic like a buffer.
Instead of allowing the attack to overwhelm your website, we filter and distribute the attack traffic across our global network of data centers using our ANYCAST network.
No matter the size of the attack, Cloudflare Advanced DDoS protection can guarantee that you stay up and run smoothly.
Want to learn about DDoS attacks in more detail?
Explore the Cloudflare Learning Center to learn more.
Mindbody specifically focused on the health and wellness space and was built by people who were passionate about health and wellness.
We serve health and wellness businesses all over the world.
We allow our customers to spend more time focusing on the parts of their business that they love and less time worrying about scheduling, software and payroll and other day to day administrative work.
We want to protect customers from attacks that could hurt their business and their brand.
And at mindbody, we're passionate about ensuring that our customers' data is secure.
When we first approached Cloudflare, we had a lot of different tools in our security stack and there was a lot of management overhead associated with all that kind of complexity.
I think at one point we had four different WAFs, a separate tool for bot management and TCNs, and we basically managed to consolidate all of that into using just Cloudflare without losing any of the functionality or any of the protections that we had in place.
It was the kind of tool I could hand to junior analysts or senior engineers, and they would all know how to manage it pretty quickly.
With our old environment, we were constantly fighting botnets and attempts to scrape our inventory Credential stuffing attacks.
When we moved Cloudflare we were able to mitigate a lot of these kinds of attacks much easier and more consistently.
Using Cloudflare bot management, we see a lot fewer false positives with actual valid end users using our application and being flagged as a bot.
We've gone from dealing with several per day to only a few per week.
With the Cloudflare access solution, we are able to provide Zero Trust access to sensitive internal applications to contractors and third party vendors.
It puts our internal applications behind strong authentication protocols and allows us to ensure that only authorized users are able to even see the service.
The health and wellness industry is only going to grow.
I think mindbody is going to be part of that rising tide that floats all boats.
Cloudflare will help us scale and grow and secure all those services as the industry expands.
Q2 customers love our ability to innovate quickly and deliver what was traditionally very static old school banking applications into more modern technologies and integrations in the marketplace.
Our customers are banks, credit unions and fintech clients.
We really focus on providing end to end solutions for the account holders throughout the course of their financial lives.
Our availability is super important to our customers here at Q2.
Even one minute of downtime can have an economic impact.
So we specifically chose Cloudflare for their Magic Transit Solution because it offered a way for us to displace legacy vendors in the Layer 3 and their force base, but also extend Layer 7 services to some of our cloud native products and more traditional infrastructure.
I think one of the things that separates Magic Transit from some of the legacy solutions that we had leveraged in the past is the ability to manage policy from a single place.
What I love about Cloudflare for Q2 is it allows us to get ten times the coverage as we previously could with legacy technologies.
I think one of the many benefits of Cloudflare is just how quickly the solution allows us to scale and deliver solutions across multiple platforms.
My favorite thing about Cloudflare is that they keep developing solutions and products.
They keep providing solutions. They keep investing in technology.
They keep making the Internet safe.
Security's always been looked at as a friction point, but I feel like with Cloudflare doesn't need to be.
You can deliver innovation quickly, but also have those innovative solutions be secure.