💻 What Launched Today at Full Stack Week
Presented by: Luke Edwards, Jon Kuperman, Kristian Freeman, Zaid Farooqui
Originally aired on February 9, 2022 @ 7:30 PM - 8:00 PM EST
Join our product and engineering teams as they discuss what products have shipped today! Read the blog posts:
- Announcing native support for Stripe’s JavaScript SDK in Cloudflare Workers
- New Stream Player customizations to boost your video experience
- Launching a Startup on Cloudflare Workers
- An Open-Source CMS on the Cloudflare Stack: Introductory Post
- Build your next video application on Cloudflare
Visit the Full Stack Week Hub for every announcement and CFTV episode — check back all week for more!
English
Full Stack Week
Product
Transcript (Beta)
Hey, everybody. Welcome back to another edition. I think actually the final edition of what launched today at Full Stack Week.
Every day this week, we have been celebrating here at Cloudflare, all kinds of product announcements and releases.
And these segments that we've been doing every day are a great way to hear from the blog authors and the people building all this amazing stuff about what it is we're working on, why we're excited about it, and also taking questions, which I think you can find if you're watching on the Cloudflare TV website, there's an email.
You can send in questions if you want, or you can always reach out to us on Twitter as well, and we will get all your questions answered.
So I'm Kristian, I manage our developer advocacy team, and I have Luke, Jon and Zaid here on the call with me as authors of all kinds of interesting and cool stuff on the blog.
So I'll give them a chance to introduce themselves.
Luke, you want to start? Sure. Hey everyone, I'm Luke Edwards.
I'm one of the lucky developer advocates that Kristian gets to manage.
Well, mostly like I get to work with everyone here, but yeah, very excited about everything we've been pushing out this week.
It's been a long time coming.
And yeah, Jon, take it away. Awesome. Yeah, I'm Jon Cooperman. I work on the developer advocacy team as well.
And yeah, it's been a really fun week.
It's been kind of cool capping it all off with the stuff we launched today. Hey, my name is Zaid.
I'm the product manager on Cloudflare Stream. And yeah, I'm here to chat about the announcement today about all the things we're making available in the stream player.
I'm muted.
There we go. As I say, on our team, I feel like we're very big fans of Stream, as you might tell from the fact we've released some stuff today.
So I'm super excited to get into that.
And maybe that's a great place to start with Jon, who is kind of standing in for both himself and Adam, who's the co-author, but due to times and stuff, he couldn't make it.
So you guys built a really interesting open source application using Stream and a bunch of other tools.
You want to talk about that?
Yeah. Yeah. I'd love to. Yeah. I think it started, I don't know, a few weeks or a month or so ago, we were hanging out with the Stream team and just looking at all of the stuff that they've been shipping and started realizing that, especially with all the cool stuff we were doing with pages and pages with workers and things like that, that we were really at a point where you could build, pretty easily build an entire production app just using Cloudflare technology.
And so we kind of set off, Adam and I kind of set off to go and do that and build it.
And it came together really fast.
And so basically what we had done is we took a pages application, we use the new pages with function stuff for all of our workers and then the Stream APIs.
So basically we have a web app that we made. It's got an admin and a public section.
The admin section is gated by Cloudflare access, just because we're trying to use all Cloudflare services.
And so right now it's like, if you have a valid Cloudflare email, you can log into the admin page where you can upload videos or mark them as private or public.
And so uploading videos, we use the Stream API for, and then the public side too, we use the Stream API and the Stream player.
So basically, you go in the backend, you can upload any videos you want.
We have a little piece of metadata, which is public. And so we kind of toggle that on and off in a worker.
And then, yeah, on the front end, we just hit the Stream API with that account and display a big list of all the videos.
And then when you click on one, it starts playing. And so it's kind of like, I don't know, like a micro example of what you could do, like building a YouTube site or something like that.
And then we started playing after we had built the initial version with the live stream stuff, the stream live offering.
And it was really, really easy just to add a whole live stream feature as well.
So now you can go into the admin page and you can either click upload, or you can just go right away and start live streaming.
And the live stream will show up as a video. So really, like all the stuff that you would, I think all the stuff that we could dream of wanting, if we wanted to build like something that, you know, was kind of like Twitch or like a private learning site, that was like another idea that we were playing around with.
Or like, you know, a video sharing, you know, could be company backed or could be public, or you could easily have a little bit of state like is public and toggle both.
So yeah, there's a lot of fun. We wrote a blog post, detailed like stuff, how everything works.
And then we open sourced the code for it as well.
So anybody that wants can go check it out or fork it and kind of build their own video apps.
I actually didn't know that there was a live streaming component to it.
That's pretty cool.
Yeah, it's really cool. And everything that the engineering teams build just layers so nicely together.
So it was like, if you go look at the code base for it, it's like pretty minimal, like just adding live stream was like a very easy thing.
And Cloudflare access like adds a nice header. So just everything that we did, like every step along the way was like, you know, kind of surprising, we think of a feature, and we'd have like three lines of code, and the feature would be working.
So yeah, it was a lot of fun. And the code's all on GitHub to check out.
I have a question for John. As you were building this, how much did you feel like you needed to learn about video technology, like, you know, the beyond, you know, just as a consumer of?
Yeah, like, really close to zero, which was exciting.
Like, we didn't, we didn't have to do too much to get it working.
And like, videos, I love video, but it's always been like, kind of a fear for me, as an engineer, like I, as a front end engineer, especially like, every time I've worked on a video app, it's been kind of a big undertaking, like trying to understand, like, like encoding and trying to understand formats and like trying to understand all the stuff.
So I felt like using stream, for me was, it was really nice, where I was just like, Okay, I don't really need to learn a lot of that stuff.
Like both the upload and the view functionality was like, very, very easy to implement without learning too much about the underlying technology.
So yeah, it was not a lot, but in a good way.
Yeah, I think that that is something that I'm really excited about, as well as you don't need to, like, know what transcoding is, and, and like, how to, I mean, literally any, any, like, codec stuff or anything.
I mean, it stream takes care of all that for you, that stuff.
I, I don't, I mean, every once in a while, like geek out and learn about that on my own time, but it's not really something I want to, like, be on the hook for in production, you know, so.
Yeah, I'm glad you said that, because that's something we, you know, when we are thinking about what we are building, and how one of the key exercises we do is what vocabulary can we eliminate?
Yes, for our customers, right? What are concepts that they no longer would have to think about?
Yeah, it's been very good. And every time you eliminate one, a word, it means you're really opening up hours or days of capacity for our customers to really focus on what makes their idea unique.
I totally agree.
And, like, I have twice at, at jobs I've had at big companies gotten put on, like, video teams, or teams that were supporting video, and it's, it's not been bad, but it's always been a surprisingly large undertaking.
You know, we need to end up hiring up a team for it, or, like, contracting out, and there's, like, all these different issues that we run into with formats, and encoding, and transcoding, like, all this stuff.
So yeah, it was really great to be able to build a video app, and for all intents and purposes, it was the same as any other kind of CRUD data app for us.
Like, you know, it was just, it was, like, the same as an image app, or the same as a blog app with, you know, uploading stuff, and then displaying it, and embedding it.
It was, it was really easy, so that was great. We already use it internally, internally a little bit, too, with our team.
Like, Adam, so one of the things about it is, there's signed URLs, and so it's, like, private access for watching certain videos, and so, you know, since you guys have made this example, there have been some links thrown around our team where it's just, like, specifically meant for us, and they're short-lived URLs, and that was all basically came for free, and I didn't know how to do that, so I jumped into that part, and was like, oh, that's pretty interesting.
Yeah, yeah, yeah. Yeah, I mean, I think the underlying champion of all of this is Worker, right, because Worker is, like, all of this is standing on top of it in many ways, so generating signed URLs, if you use Worker, then you basically don't need your own backend, and it's, it's, you don't need your own origin.
You can just use the Worker to call the Stream API, or other JS APIs to generate the token.
Yeah, I think that there is so much exciting stuff, like, we're still beginning to explore with, like, Workers and Stream, and Stream Live, too.
I mean, we talked about Stream and, like, all that video stuff.
I feel like live video is literally a whole nother set of, like, you're talking about, so, like, vocabulary and stuff like that.
It's, like, I don't, I don't want to deal with, or, like, there's just, there's going to be people who are smarter about that kind of stuff than I am.
I would love to have them manage that stuff, right?
I mean, you're going to be part of the idea when you have ideas or features that excite you.
I think many of us, we're builders, so we start picturing it in our minds of what the finished product's going to look like, and that excites us.
But all the underlying details, you know, and that's where I think we, on the Stream team, we work hard that, how do we, because I feel like that excitement has a TTL, where if it gets too tiring, people kind of give up on the idea.
So, like, how do we just make sure when people have exciting ideas around video, the excitement doesn't die out because they get bogged down figuring out tiny details that have been figured out by lots of people over time, but just not turn into a product.
Yeah, and I think the push previously, like, kind of before Stream was to just use, you know, just to use one of these mega platforms to just kind of go, go all in, go host your videos with them and go just link to their, you know, to your channel on their site or whatever.
So, I think that, especially because I'm someone who really likes, you know, owning my content and owning the experience around it, like, it's just a really nice, like, abstraction.
It's like the right place that I want to be able to, like, I don't want to go all in and learn a lot of deep video stuff, but I also don't want to just simply link to, you know, a Vimeo or a YouTube channel.
I would like to have my own experience.
So, yeah, it's a really good abstraction point, I think. I haven't had a chance to really play with Streams yet, but it definitely fits that, you know, that kind of no man's land that there had been, right, where it's just, it's just streaming primitive is what it is, and you can build and customize it to your heart's content and not have to relinquish full control of your content to someone else and then be, you know, at their beck and call for whatever they decide to do with your content, their latencies, their whatever.
Like, it's, you get to do what you want.
On that topic of, like, customization and stuff, this might be a good way to sort of segue into the other Stream announcements today around customizing the player specifically.
Do you want to talk about that, Zed? Yeah, so we announced, so when we built Stream, when we, you know, first launched Stream about a little over three years ago, we were, one of the key decisions that we needed to make was do we, should it come with a player or not, right?
Because it is very easy for us to just, you know, make the backend architecture and provide you all the tech.
But in talking with customers, what we realized was the front end is not easy.
It can be a lot of work. There are open source libraries, but, you know, that provide an open source player.
But a lot of the magic in the streaming world really happens on the front end, because the way video streaming works is the server returns to the client basically a list of quality levels that a particular video is available in.
The client, and, you know, typically the player, uses its judgment to determine which quality level is best for this user on this device under the specific network conditions of that client.
And that's something that's not very obvious, but a lot of the decision -making about, that impacts the end user experience as it really comes from the client.
And in this case, a player. So, we decided that it was really important for us to have a player, and we really focused on making the, you know, the heart of the viewing experience as stable and high quality as possible.
So, it means, you know, reducing buffer times, right?
Nobody likes, like, videos that buffer. Having the best quality possible for the given network conditions for a particular client from, you know, different parts of the world.
What we didn't focus as much on is letting you customize the player.
So, sure, you know, the heart of the stream pitch is no ads.
Like, that's just not in our culture, right? No branding. So, you're not going to see any, like, software logo or anything like that on it.
But we didn't really focus on, I mean, that's a good start.
But that's not the most exciting part of what the player could be.
So, the announcement today lets you really customize the player.
So, we announced a way for you to give us the, you know, the color of your primary color of, like, your brand.
Or, you know, a common use case is platforms that cater to creators.
So, creators have their own brand, right?
That they're using the platform to manage. And really allowing that platform to allow their creators to customize the player for their look.
So, there are multiple levels of, I think, abstraction here.
And we want to enable all of those different stakeholders, not just our customers, but our customers' customers, to be able to really make the viewing experience in line with their brand.
So, the announcement today lets you customize the player. So, by adding a primary color.
It also lets you, you know, turn on captions. So, a stat that even surprised me is that 85% of videos on Facebook are played in a muted state with captions.
And obviously, when something's muted, captions become so much more important, right?
We wouldn't think about it, but I guess if you browse through Facebook, you can see, like, it's not something you think about.
But when you look back, you can, the statistics begins to make sense, right?
Maybe one in, like, 30 videos we come across is, like, interesting enough where, like, I want to click on it and actually listen to the audio.
The majority of them, even, like, on Instagram, you just scroll through.
You watch it for a few seconds, 10, 15 seconds, you read the captions and you keep scrolling.
So, previously, implementing something like that with the stream player required a bunch of custom code on the front end, right?
You could use the SDK to enable this. But now, we've really simplified it.
So, you can give us a country code and you can, assuming we have the caption file or the language code, we will automatically show that language.
This is also really good for localization. So, if you're using on your corporate website that is in multiple languages, what if someone goes from English to, say, French and someone switches the language?
Now, all of your content is in French, right?
Except you have a video and the video, the audio in the video is English.
And if you don't have subtitles turned on or captions turned on and automatically selected to French, it's going to be an awkward experience, right?
So, with these features, we're really hoping to, you know, increase the accessibility factor of video on the Internet.
And, yeah, and cater to wider audiences.
I love that. I love all of it. I love the accessibility stuff.
That's a big passion for me. But then, I love hearing you talking about, because this is such a Cloudflare thing we're not necessarily building just for people to use us.
We're building for people to build, for people to use them using us.
It's just a really interesting take where we're, like, we're not going to put our logo on there.
And also, we're going to give you a chance to put your color logo on there.
Because we're building stuff. I love it. I love hearing about that perspective.
I think that's a very, like, unique Cloudflare thing that I really enjoy.
Yeah, I agree.
I was looking at the brand color thing in particular, and I hadn't even thought about the idea, like, you're talking about, like, if you're a service offering, like, people can upload their videos.
Like, they can customize their own brand.
Like, yeah, there's just this, like, extra level of, like, how we think about things here that, yeah, that I really, I really like.
So, cool. Yeah, I mean, I think Stream, like I said, we're on our team.
We're all really big fans. We're excited to work with it more.
So, I'm super excited to see those updates. Cool.
So, moving along. Luke, you published something today on open source, full stack production CMS slash SaaS example.
Maybe you'll do a better job of describing it than I will.
Why don't you take it away? It's a mouthful. There's a lot of hyphens there.
So, yeah. Today, we're releasing a, well, we did release, and we are committing to continue building a open source production, production-ready SaaS application, right?
And so, we are using the CMS or content management system as the example SaaS application, which does mean it will be on its own immediately useful for ourselves, but for users, right, where, you know, people for a while, our community have been asking for some kind of CMS-like solution.
And so, we're fitting, filling that need, but, you know, not because it's a CMS, but because, you know, it fits really well for the kinds of things or the kinds of troubles people tend to have with a, with the Cloudflare stack.
So, I've answered this question a few times on Twitter already, but we are using Workers, Workers KV, rate-limiting Cloudflare for SaaS, like a whole bunch of things.
And where the CMS fits into that is that, you know, because all the data is being modeled into Workers KV, it's a great way to show, like, here's how you can model a bunch of different data entities and their relationships to one another.
And the way it's built out, the applications built out, you can customize it, you can swap out KV for durable objects, you can swap it out for a database connector, which we also announced earlier this week.
The entire purpose is meant to be an all -in-one, like, starter kit for your next product or your next SaaS that you plan to launch.
And so, the reason it, you know, we're able to call it production-ready and a SaaS is it has all the integrations you would expect to have at, you know, a startup or at any company.
And that includes Stripe integration, you know, SendGrid for transactional emails, logging, error reporting, like, the works.
So, really, it's everything, batteries included, you remove things, you customize things as necessary and go from there.
I think this is something we talk about a lot where we have all of these amazing, I mean, like, Stream is a great example as we have all of these really interesting products.
And they're basically just, like, begging to be put together, right? Things like workers and KV, Cloudflare for SaaS, rate limiting, like, all of these things.
And whenever we put them together, the result is so interesting and I think really compelling for people to, like, hit the ground running with whatever project they're trying to build.
So, this is a great, yeah, a great example of that. Can you talk a little bit about, like, how you kind of envision, you don't have to, like, you know, go into a ton of detail, but just, like, at a kind of a high level, how you envision, like, the different stages of it to work and, like, is there a way for people to, like, kind of follow along with that?
For sure. Yeah, I was realizing that I forgot that detail.
So, it is going to be developed in public. As mentioned, it's open source.
And so, people can always check in and grab what's there, but check in with these milestones that the blog post announced and laid out for the project.
So, we're starting with a phase one and that's a complete JSON API that is doing all of the business logic that you would expect this thing to do.
So, that's where workers, workers KV, like, rate limiting, Cloudflare for SaaS, all these things come in and that on its own will be a complete product.
And we'll also set the stage with, you know, CICD, unit testing, like, full development, best practices, like, the works, right?
And then we'll move into phase two, which is an actual, is where it becomes as a pages integration.
So, there will be a dashboard admin UI, right?
Where you can actually interact with the phase one content beyond curl, right?
Like, beyond just throwing HTTP requests at it. And along with that, you know, there will be integration with the new pages with functions work, where some of the API or all of the existing API may be reworked into the new functions directory mapping.
And that's not to say that, like, phase one on its own is organizing correctly.
The purpose of this example is that it's a living example and shows, like, how a project will evolve over time.
And where this also comes in is phase three and phase four.
But phase three adds, I call it article edge rendering.
But server side rendering with a worker that is actually rendering the articles, the documents that you've been saving, where it turns the CMS from a headless CMS into a more standard head full or monolithic CMS, where you can choose your template, you can choose your styles, whatever.
And it will render it out into HTML.
That's adding more pages with functions integration. It might be adding workers integration, adds more caching layers, a bunch of things.
And then the final phase, which is a more open -ended phase, is what I call feature upgrades.
And that's where, again, if you look at, like, the standard evolution of a product, phase four will start adding exciting features like stream, right?
Like, there's no media assets involved in this application yet.
But R2 will come into play, our storage solution.
Cloudflare image will come into play. Stream will come into play.
So, it's not just, like, hey, here's a bunch of content.
Markdown content that is being rendered either as JSON or HTML will also include durable objects for possibly custom rate limiting.
But definitely include durable objects for, like, a collaborative document editor.
So, there's this concept of, like, users and organizations.
A user can have its own project or an organization can have a project with content.
And so, you just are live editing the same thing.
So, those kinds of things. It's definitely going to be a long-running project.
And so, people are definitely encouraged to check in with it, have discussions.
We're very open to discussions with this. But, yeah, it's going to be exciting.
Yeah. And I'm pretty surprised. I mean, like, people are already checking out on GitHub.
We have our work ahead of us. Lots of people digging into it and excited about it.
So, clearly, something that the people want. So, cool.
Well, we have just a couple minutes left. So, we'll tackle the last blog post here, which is one that I wrote around Stripe's native support for Cloudflare Workers.
So, this is a very long time coming. Earlier this year, we basically posed the question to people in our community and developers using Workers, like, what kind of JavaScript packages that aren't currently supported in Workers would you like to see as support?
And I believe that Stripe, the payment processing tool, was either number one or number two.
It was up there. It's like right at the top.
And the reason for that is that Stripe makes things really easy when it comes to payment processing.
They also do a bunch of other really interesting stuff.
Last year, I wrote this example application. It literally was about a year ago.
It was on Black Friday. It feels like it was half a decade ago, but that's okay.
But basically, using Stripe for all kinds of things. And the unfortunate part there was because of the way that Workers, like the platform, runs on V8, it doesn't run on Node.
And so, there's a lot of these core Node dependencies and a lot of JavaScript projects that Stripe was one of these.
So, it had a lot of dependencies on like net HTTP, which is like Node's HTTP library.
And there's just a bunch of these dependencies that made it really hard to use Stripe inside of your Workers projects.
So, we worked with that team and got it working natively.
So, it just uses the native... It basically fallback to native browser APIs as needed.
And so, now you can basically take any code sample. So, whether that's accepting payments or creating a new subscription-based product, literally anything inside of the Stripe documentation and their huge collection of examples, all of those now work inside of Workers.
And so, this blog post just covers some of those and some of the use cases.
And I also think it's just a great kind of follow-up from when we talked about support for Node packages and things like that in the past.
Like this idea that we are working with different JavaScript developers and things like that to support those tools inside of Workers.
So, this probably won't be the last time you'll see one of these big libraries that we've been working to get support for in Workers.
But this is just a particularly exciting one because people have been asking about it for a long time.
So, yeah. And I guess the last thing I'll say is there's a bunch of open source code and things like that that we've released as well, which you can find in the blog post.
Some use Workers. Some of them use the Pages functions stuff that we announced.
So, they're very kind of current and up-to-date.
They're a great place to get started if you want to make money with your Workers projects and your Pages projects.
Right. I think one of them, and it's like from the blog post, is stripe.pages.dev.
And that is the official Stripe checkout example deployed as a Pages app using Pages with functions and using the Stripe SDK.
So, it's like an all -in-one and multiple things from this week's announcements just wrapped up into one repo for you to check out.
Yeah, I love that.
And then, Christian, do you want to kind of help folks? Where can they find us?
Like all the different places if they want to get in touch or check out stuff or hang out?
So, go to Cloudflare .com. There's a link to the Full Stack Week page.
You'll be able to find all of the old... No, I don't want to say old. It's not old.
It's literally four or five days at the oldest. But like all the stuff we've been releasing, all the blog posts.
Join our Discord, workers.community. That's like the Cloudflare Developers Discord if you're building with stream or Workers or Pages.
We literally have like 10 seconds left. So, I'll just give everyone a chance here to say goodbye.
Thank you, everyone. Yeah, thanks so much. Thanks for tuning in.
Bye.