What is serverless #4 | Developer experience and Collaboration opportunities | Prismic

- So, one of the things that I wanted to cover in this videos, so, we talked about different things. We talked about scalability, about deploying globally. And, there's one that is very important, the Developer Experience, and, you know, whenever you're working, the thing that I like about Serverless is that it doesn't integrate into the project by the end. It's since the beginning, since the start, it's there, and it's there for several things.

So, can you tell me some of the advantages that you see about Serverless for the developer experience? - Yeah, in terms of Developer Experience initially, when Serverless was kind of getting started, and even until today, the primitives are quite hard to deploy. So, in essence, the technology is very simple, as a serverless function. But everything around deployment is very hard, and that's where we try to simplify it and make it one command. - Because, number one is simplifying deployment.

- Yes, and you write your functions, you say what technology these functions are using, like, are they Next.js? Are they Node, are they Go? And then, you run Now, or you Git push, and your deployment comes alive. A deployment, in itself, is made up of one or many serverless functions, or static files as well, like CSS and JS assets, or SVG assets. So, from a developer experience standpoint,

a few things happen with this model. So, one of them is, deployments are instant. So, what we usually see is that it takes just a few seconds to deploy hundreds of these functions. So, you know, you get up and running very quickly. The second thing that happens is, Serverless makes it possible to afford to run, or "run", because they're not really constantly running, many, many versions of your deployment. So, it takes away the burden in the developer's mind

that they cannot deploy infinitely. Every little change they make, they can deploy. Every push gets tested, built and deployed. So, you can access the live version of any state of your application throughout time by just, for example, going to Github, with which we intergrate. - So basically, if I understand, this means, if I have a Pull request, I can associate a function to that, like a deplyment, a URL to that.

- Yeah. - And even if I'm not using it, I'm not paying for that. - Right. - And the moment someone clicks on it, it boots up, and even if it was done one year ago, they still see that version running. - We never, we kind of take the same approach as Gmail. When Gmail came out, they were like, "You know, we don't need the Delete button." Because, when you delete email, it's forever, and you lose it out of search, so that was their argument for doing that. And for us, it's not about search, although that's helpful as well,

but it enables very important features. Like, you can review old versions of your projects. You can analyze the evolution. If you work on marketing, you can compare your changes over time, like, "Oh, this is what our marketing campaign looked like. "This is what it looks like today." For people that are more on the application side of thing, not just the front-end or marketing side of thing, they can think about rollbacks. Like, what happens if something went wrong? I can quickly go back to another version,

and it doesn't even require real deployment. - It's there, it's there. - It's there, it's instant. - And, also, what I like about it, if I'm working on something, and then I want to give a preview to someone, it's there, right? You just send them the link for collaboration. - Yeah, the link is always there. It's like everyone gets their own personal staging environment, with the advantage that it's not even staging per se, because it's running with the same exact