Cloudflare TV

💻 What Launched Today 2022

Presented by Kabir Sikand, Leroy Lasenburg, Sam Marsh, Igor Minar, Matthew Bullock, Mia Wang, Nevi Shah
Originally aired on 

Join Cloudflare Product Manager Leroy Lasenburg, Sr Director, Engineering Igor Minar, Product Manager Kabir Sikand, Product Manager Matthew Bullock, M&A and Strategy Director Mia Wang, Product Manager Nevi Shah and Group Product Manager Sam Marsh to learn more about what launched today for Developer Week.

Read the blog post:

Visit the Developer Week Hub for every announcement and CFTV episode — check back all week for more!

Developer Week

Transcript (Beta)

But. Hello.

Welcome, everyone, to the latest installment of what's launched for Cloudflare Developer Week 2022.

My name is Leroy Lasenberg.

I'm the product marketing manager for the Developers platform.

And today we have some amazing speakers that's going to share some great announcements and product news for Cloudflare's Developer Week 2022.

Let's start with Sam.

Can you introduce yourself, Sam?


Thank you. Yeah. My name is Sam Marsh. I am the group product manager here in our application performance team, and we're responsible for a range of functionality from how traffic gets to Cloudflare, how we handle it once it's in Cloudflare and where we send it afterwards.

All right.

Next, we have Kabir. Hi, I'm Kabir from the product team on Workers.

I helped build deployments, which we're going to talk about today as well.

Next, I have Igor.

Hey there, Igor Minar engineering director at Cloudflare, working on our workers development platform, and I primarily focused on building, develop experiences and researching how a platform can improve web experiences for end users.

And Nevi. Hi, Nevi.

I'm a product manager on Igor's team. On the Experiences team working on Cloudflare Pages, which I'm really excited to talk to you all about today.

All right.

And last but not least, Mia. Hi, I'm Mia Wang, I lead Strategy and M&A at Cloudflare as well as our Workers Launchpad.

All right.

All right, so let's get started. Sam, what are we announcing today?

Yeah, a good question.

So we're talking about Cloudflare snippets today.

It's basically a new product we are building right now we're actively working on.

And the whole idea is to kind of give customers more control and give them more options in terms of what happens to their requests and their HTTP requests when they arrive at Cloudflare.

So typically we have this kind of split whereby there are a number of quote unquote out of the box products that are available for customers to use.

And we've launched a lot of these in the last 12 months from transform rules to origin rules, cash rules, redirect rules.

And the idea is we kind of take that functionality and that power when we package it up so that anyone can use it.

But as always, with kind of these use cases, and when we speak to customers, there's always that kind of 1% whereby they can do everything they want apart from this one use case, and that's when they either have to leave that use case kind of on origin on the service that is currently or they kind of have to go and deploy like a full worker and then start to incur costs and so forth.

So what we what we kind of formulated and what we're building is essentially snippets whereby a customer can look at what they're trying to achieve.

They can try and do that in a product like Transform Rules and say, I want to add a custom request header, I want to do it via a transform rule.

They try and do it.

It doesn't quite work. And rather than fall back to what the kind of current options are, they can just literally throw in a piece of JavaScript, modify the header, put a function in there and it just carries on.

They can carry on doing it.

So we really helped unblock them.

And the really cool thing is we're trying to offer this as close to free as possible.

So there'll be a certain amount of snippets of pieces of code that can be available on each plan level included at no extra cost, and there'll be a pretty aggressive, pretty high fare usage cap as well.

So we really want to encourage people to go out there, kind of find all this code that's lurking, all these kind of all these kind of functions that are lurking in their environment from BCL to Apache to access to Engine X configs.

We're going to go out there and find those and bring them to Cloudflare, put them on our network and not have to worry about them.

And this is kind of part one in kind of that story.

Part one is giving them the platform to do this as little to no cost as possible.

And then part two is giving them an even easier way to do this.

It's giving them a way to say, here's a blob of VCL, here's my access file, put this on Cloudflare and do everything for me.

And we take that file.

We take that kind of block of code.

If they do it like that and we say these two here, our transform rules, this one here is an origin rule.

And these three they're snippets and we kind of do it all for them automagically.

So we keep chipping away at that barrier to entry.

We keep making it more accessible and we help these customers take all this janky on prem legacy stuff that they might not know about, all that they kind of want to get rid of.

And we make it as easy as possible to kind of put it all in one place where they're kind of looking every day.

And where can we find more information on snippets?

So the blog launched today.

There's a lot of information in there in terms of what we are thinking.

It's in development right now, so there's not a huge amount out there except for the blog.

There's a sign up form in the blog right at the bottom. So if you are interested in kind of testing this up, we expect to start inviting people into the closed beta sometime in the first three months, next next year.

So if you do like what you read and you are interested, then hit that button, put your information there and we'll reach out to you.


Okay, And again, all the information and all the announcements are going to be available on Cloudflare to select the developer week 2022 button and you'll be able to see Sam's blog on snippets.

So thank you, Sam.

And any other comments or anything you want to share? No.

Okay, Perfect.

All right.

So next we have compare copier. What are we announcing today?


So we're announcing deployments today. You may have heard something similar if you've been following the page's product or have been using that over the past year.

We wanted to bring some very similar version control and audit log functionality to the Workers product.


And who benefits from deployments? Are there any particular use cases you can refer to?

Yeah, absolutely.

So deployments are really an audit log that lets you keep track of all of the changes that you've ever made to a worker on a go forward basis.

So let's say you pop into your worker from the dashboard and you change the usage model over to unbound because you want to take advantage of a lot longer CPU times and the lower cost per request.

Or you wanted to add another worker and split it up into two different workers and make little microservices.

You could do all that every time you make those changes.

We will issue a new deployment and we'll keep track of it for you and you'll see exactly where that deployment came from.

So your developers, your team leads.

Anyone who's taking a look at issues that have come up along the way, they'll be able to see exactly who made changes to your worker when they happened and where they came from.

We keep track of sources like Dashboard Wrangler API, TerraForm. We'll also keep track of who's made those changes.

So if it's an API token or a specific user on your account and that way you can see if something happened out of band or by mistake, you'll know exactly when it happened.

And it's perfect.

And where can users actually get more information on deployments or where can they get started with appointments?


So it's available today in your dashboard. You just go into any one of your workers.

There's a deployments tab.

You'll also see that at the top of any of your worker detail pages we keep track of, which currently active deployment is on Cloudflare's Global Network.

You can click on the link in the top and it'll take you to the deployments.

Page shows you a brief history of all the deployments that you've had.

You can also see all this information in Wrangler.

So if you're using Wrangler at scale to to manage your worker or push for changes, any time you publish from here on out, you'll see the deployment ID gets displayed in your Wrangler output.

You can use that to find a deployment in our API.

And then you can also use a new Wrangler Deployments command to list out a history of all of your deployments.

You'll also see which one is currently active.

And that's always the most the most recent deployment that's been made.

But I do want to shout out that this isn't just the only thing that we're going to be building.

So deployments give us a really, really good basis to build out a lot of the things that our developers have been asking for some time now.

So we've heard that folks make make mistakes when they build code and they send it up to Cloudflare global network.


There's always there's always a chance of failure when you make a new deployment.

And so we want to make sure that our developers can catch those issues and they can roll back to previous good states or good versions.

And so the next things that we're going to be working on are things like rollbacks and being able to view any of the changes that you've made in detail within that audit log.

So you can go into your deployment history and you can say, Hey, let's look at three versions ago.

I know it was working.

What did what changed since then?

We can see that maybe someone updated a binding or they changed an environment variable or a secret.

And that secret is no longer valid.

And my stripe API is now returning failures.

Well, we can just roll back to one version prior or two versions prior where it was in a good state, and that just should take seconds instead of minutes or having to architect any sort of sicced pipeline would GitHub actions or anything else.

It's something that's on platform. We want to bring it to our users so you can really easily do that from the UI or dashboard or Wrangler or any sort of automation that you have.

And beyond that, we want to make it automated, right?

So, so some users are looking to automatically deploy new changes to the Workers platform whenever they commit code to their repos.

If you take a look at our blog post that we announced today, you'll see in the what's next section, if you have any sort of feedback around how you're doing your deployments today, how you want to do deployments in the future, there's a little button at the bottom that says, Let's chat.

We'd love to hear from you.

We'd love to get any of your input as we're building out some of these next phases of what deployments look like and how we can innovate on developer experience.

So please give us a shout if you'd like to chat. Yes, definitely.

And also join us on our Discord community as well.

If you have any questions or you want to provide your feedback.

Thank you.

And I wanted to say, like if anything that could be said sounds vaguely familiar.

You know why?

Pages and Workers are like very similar products.

We're working to kind of understand how these two products kind of work together, how we can make it easier for you as a developer to sort of come and use our products and kind of know which one to use versus the other.

So our team in my team will work really closely together on pages as well as workers to kind of make that experience more.

Which is a great segway to your Nev and your announcement, You and Igor.


I'll start off. You are and then I'll pass it over to you.

So pages historically on the Workers platform is the developer experience product, right?

We care so deeply about how our experience on pages feels to you as a developer, how you think of projects, how you collaborate on projects, how you deploy your projects.

And so every time we kind of ship out a bunch of features in a quarter, that's at the forefront of our mind.

So a year ago, actually, I think to this day, a year ago, we announced that Pages was a full stack platform so you could easily access the Workers platform from within pages to add dynamic content to your site.

It's been in beta for a year.

We've learned a ton from all of our beta testers, so shout out to all you beta testers for giving us feedback.

And so today we're really excited to announce that it is generally available.

So what does this mean?

What have we added? Some of the cool things I want to kind of highlight is, Well, first of all, what are our functions?

Let me give you a quick recap. Yeah.

So like I said, functions are being able to access Workers from inside the pages platform the way you are.

And I kind of like to think about functions is functions are kind of special caseworkers or my team also likes to say workers in disguise.

Basically you are from within the Pages platform as you do kind of that git deployment workflow.

If you add a slash functions folder to your directory, we will deploy your functions alongside your static assets.

And so basically what we're doing under the hood is we're taking all of those functions, bundling them into a worker and deploying it on your behalf.

So super cool if you love workers, but you love the Pages, kind of like UI experience.

The Wrangler experience functions is kind of a really great way to start building out your website.

Some of the things that we've added, we hear you debugging a function was really difficult during the beta because we didn't have any logging.

We've heard you and we're adding this today or we have already added it.

You're also able to see functions metrics so you can see successes and failures as well as request counts and some request data on that.

My favorite part of this announcement is actually the bindings piece.

So with Pages functions is kind of like that puzzle piece that connects you to the rest of Cloudflare.

So we had a really great D1 announcement yesterday. If you want to build Pages and pack it with the one database, you can use functions to do that.

So we have support for our two bindings.

D1 bindings, Durable Objects, KV what am I missing?

And then bindings for Queues and Workers Analytics engines will come, come soon into the future.

We also have support for our secrets, which has been on the requested features list for a while.

And then also my other favorite announcement is we announce support for Full-Stack Nexus Framework Support.

A couple weeks ago there were some requests for support for next 13.

That's another sort of framework that we are supporting now.

But Igor, tell us a little bit more about some of those frameworks that are supported on Pages.


So now that we have functions available, we actually have compute on the server side that allows us to do interesting things.

You can use it for, as we mentioned, for building APIs or doing some kind of business logic on the server side, but you can also use it for server side rendering and server side rendering is one of the key optimizations that make web faster with many of the current solutions that people use for building front ends, whether it's React or Angular or Vue, you typically start with client side applications.

You just write a bunch of JavaScript, you deploy it as a static page, and the browser loads all of these assets and renders the UI on the client side.

This is a very easy way to build applications and it allows you to create very rich applications.

But the downside is that in order to paint anything in the browser, any kind of UI, you have to download all of this code, all of this JavaScript code, and execute it on the client side with functions and with full stack frameworks.

You can actually optimize this and you can start by rendering the UI of your website or your application on the server side so that the browser can instantly show something to the user.

The user feels like they can start reading the content or start interacting with the content while the application is bootstrapping in the background.

So and then we mentioned that there are some solutions that we previously announced that we supported for this kind of server side rendering Full-Stack way of building applications that will support it in the next few years.

And today we're announcing that we are also supporting other solutions like Quick Astro next year.

And so let's start solid.

Apologies to Ryan.


Yeah, so let's start.

So we have with these four solutions and the previous two that we announced, we have pretty good coverage of the front end ecosystem.

So no matter how you're building your application today, you can come to Pages and Cloudflare and start building it with server side rendering enabled out of the box.

It's very cost efficient or free in many cases for smaller, smaller applications.

So I think it's a great way to build applications. I think also like one of the point of the experiences platform is not to kind of make these hard decisions of like this is the only framework or it is port or we're going to build our own framework, or maybe, I don't know, maybe that will come in the future.

But the experience of platform and Pages in general and Workers, we're really trying to meet developers where they are, right?

Like we see all these developers using all these different frameworks as a product.

I want to meet you where you are. And so this is just the beginning of like different frameworks that we want to support.

If you're a framework author and you're interested in having Pages support, definitely get in contact with us.

We love to kind of chat and see how we can get our users using your framework as well.

All right.

Thank you. Never any. All right.

Do you have any additional comments or where can customers find or use this?


So in regards to Pages, I did want to call out that as we kind of hit general availability, this kind of gives you the opportunity to go unlimited with your functions, right?

So during the beta period, we had a strict kind of 100,000 functions requests per day.

Now in we have kind of implemented a pretty simple pricing model, which is just the Workers pricing.

So if you have a Workers paid subscription functions is now included in that Workers paid subscription.

If you have an enterprise contract, a Workers under enterprise contract functions is also included in that as well, and your usage will kind of show up or will show up on your Workers bill.

So if you want more information, definitely head over to our docs and if you haven't already, join our developers Discord channel and get in touch with us if you have any more feedback or questions on it.

You're great.

Thank you.

Thank you, Igor. Appreciate it.

Or do you have another announcement? Yeah, there's another.

We've been busy, so we have another announcement.

So with.

With functions and Full-Stack frameworks, the announcement is focused on where developers are today and what kind of applications they can build today.

In addition to focusing on present, we also looking to the future and doing a lot of research in the form of what are the web architectures or architectures for future web applications.

A couple of weeks ago we announced that we started sharing research out of our micro frontend research.

A micro frontend is an area where that is very interesting to enterprise developers working on frontend applications.

The common challenge with these kind of applications, big enterprise frontend applications, is that they are monolithic, they are massive and they are hard to work on because you have lots of developers working on these applications and the code base can get very fragile, especially if you are focused on this client side based on applications.

So you have a lot of JavaScript that needs to be downloaded into the browser.

The JavaScript can get fragile, can take a long time to download, and what that results is in most enterprises or most complex applications, whether it's in banking industry and insurance, health care.

In government, you often see that the applications are not actually as user friendly as they could be.

They take too long to load.

The UI is not that great and sometimes you see the application is broken and it's not broken because the developers don't know what they are doing.

It's just the application is so massive that it gets difficult to iterate on it.

One of the one of the approaches that the industry has decided to investigate and solve this problem was use of microphone tents.

Microphone tents is a front end take on microservice architecture that is more common in the back end space, but translated over to the front end side.

And basically what it allows you to do is take these massive monolithic applications and split them into smaller applications that you can iterate on and deploy independently.

But to the user, they still feel as a single cohesive application.

Traditionally, these approaches were very much focused on client side and client side JavaScript and how can you stitch all of these mini applications to a single cohesive application in the browser?

And that has the downside of having to load too much JavaScript, which as we mentioned previously, makes the applications slow.

So one of one of the areas that we've been researching is now that we have workers, we have functions, we have this very nimble JavaScript runtime that runs at the edge of the network.

Could we utilize that to do server side rendering and bring that to the micro frontend to world where we could help enterprises scale their applications by doing server side rendering, but also decoupling these monoliths into smaller applications that can be iterated on independently deployed independently by individual teams and to the user.

The user actually gets a better user experience because we enable server side rendering.

So the application instantly renders in your browser and you can start interacting with it much sooner than you would with traditional approaches.

So as I mentioned two weeks ago, we mentioned we shared some initial research in this area where we discussed our fragments based architecture and how you can split up your monolith into many smaller mini applications deployed into individual workers and yet still do it in a way that the application renders as a single application with a single cohesive UI.

This is great if you are starting from scratch, but most applications, especially these massive applications, you rarely get to build on greenfield.

You always have some legacy that you have to work with.

Many kind of migrations or rewrite full rewrites of these applications are very high risk and high cost.

So Enterprise is very wary and they don't want to take on these big projects.

This is why today we announced additional chapter of our research, which focuses on how can we enable incremental migration or incremental adoption of this fragment based micro frontend architecture with server side rendering, and do it in a way where you can really pick pieces of the UI in your application that are most valuable and move those over to the new architecture while keeping the rest of the application as is.

So imagine that you have a corporate application and one of the things that we see is that if these applications are client side render, the use client side rendering solutions, even something as simple as logging in can take a long time.

Because in order for the logging form to show up, you need to download a lot of JavaScript.

You need to process this JavaScript, and that JavaScript then renders the log in form.

So one of the demos that we built and we show in the blogpost is how you can take your existing application that is react based productivity suite.

We just made an application and we picked several fragments of the UI, like the logging form and some of the high value fragments from once you're logged in from the application to do list.

And I think we have news, latest news and how can you move those over to the fragments based application architecture that is deployed to workers and how can you how can you do it incrementally so that.

You don't need to undertake a big migration.

We are sharing lots of demos, we are sharing the source code and we are asking the community for feedback.

I know that this is an area that is troubling lots of developers, especially in the enterprise sphere.

So if you have one of those, please reach out to us on Discord on Twitter.

We are happy to engage and we would like to exchange notes and see if the solution we are proposing is helpful for you.

Thank you, Igor.

Now it's perfect.

And again. Yes. Please share your feedback on our Discord community and definitely visit Cloudflare dot com and get all of the blog posts on our developer week 2022 button.

All right.

And last but not least, of course, saving the best for last is Mia. Mia, your announcement today?


So this one is a little bit different. It's not a product announcement, but hopefully something that will make developers lives a little bit easier as well.

So a little less than two months ago, we launched our Workers Launchpad program, which is intended for any startup that's building on Workers and our developer platform, regardless of where they're based, what they're building, the size and stage of the company, they're all eligible to apply.

And the way the program works is every quarter will select a cohort of startups who will have an opportunity to pitch the VC partners that we have involved in the program, as well as get a bunch of mentorship and support and visibility with Cloudflare and our partners as well.

And so when we initially launched the program, we had 26 VC partners that represented more than 1.5 billion in potential funding.

And today what we announced is that this group has grown now to 40 investors and we added 14 more.

And the program is now at $2 billion in potential funding. And the other exciting bit is that we announced our fall cohort, the very first class of workers launchpad startups, and it's a group of 25 really, really exciting companies ranging in businesses that are building tools meant for developers to help them deploy things a bit more easily or secure their applications or allow them to allow developers to build more privacy.

Preserving applications.

Well, all the way to.

We have another company in the cohort that's helping bring together any data that's travel related.

So bringing together data from, let's say, ticketing, website, hotel, car flights, bringing it all together so you can build applications that let your users book all of their travel on it.

So it's a really wide range of different companies representing ten different countries and we're super excited to work with them.

I think just some context on why we have this program is a little bit different.

It's sort of twofold.

One of the things we are seeing is just given the growth of the Workers ecosystem community, we now have a million developers and a really vibrant community of companies and startups building on it.

And so we were thinking about what more can we do to help them grow and scale.

And obviously for any startup, especially in these times, being able to raise money and funding and grow your team and businesses is a big thing.

So the first part is helping them with that.

The other impetus behind the program is we spend a lot of time talking to venture capital investors and other investors, and a lot of them over the last few years have increasingly started asking what is this Workers thing I keep hearing about companies using it.

They seem to love it. They talk about it as a differentiator.

I'm starting to see it in even in their pitch decks that they're building on Cloudflare Workers.

How do we get involved? How do we help support this ecosystem?

So that's how we partnered with a really great group of 40 different VC funds from all around the world.

I don't know how many countries are represented by this group at this point, but we have firms that are global.

We have ones that are based in India, Southeast Asia, Europe, really everywhere around the world.

So super excited to be working with this now group of 40 VCs and also pitching.

We're working with our first cohort of 25 launchpad startups. Now.

Perfect. Thank you, Mia. And yes, definitely be sure to visit our built by sorry, built by Workers page as well.

To see a lot of the developers work on Workers and pages as well. to I have a quick question.

I get a lot of messages about this in the Discord.

Do you have any advice for founders who are looking to apply to Workers Launchpad?

What do you look for in an application?

Yeah, that was really the question.

And then I should have mentioned to you, this is a program we'll be running every quarter, so definitely not too late to apply and be in consideration.

So we look primarily for two things.

One, we want to see interesting use cases for workers.

Are you building your entire application on us or are you moving from other products to Workers?

We really enjoy hearing those stories.

And then on the other side, especially for our VC partners, they're looking for companies that they could potentially invest in, right?

So just make sure in your application, tell the story about what you're building when you're building it or why you're building pretty much the way we structure today's conversation.

But just sort of clearly describe the mission behind your business while you're building it to explore and also just share as much as you'd like about your Workers experience.


All right, Thank you all again for your announcements again for Developer Week 2022.

We truly appreciate your time. Again, visit Cloudflare and click on the Developer Week 2022 button to read all of the blogs and announcements for Cloudflare Developer Week this year.

Thank you all again.

I appreciate your time.

Thumbnail image for video "Developer Week"

Developer Week
All the building blocks you need to create & deploy full-stack applications on Cloudflare. Tune in all week for exciting new product announcements and more!
Watch more episodes