What is Serverless - Episode 5: Building a fast website

In the final episode from our What is Severless series, Guillermo from Zeit explains how using Severless can help you to build a fast website. Integrate with any framework, mix static and dynamic, and deploy everything at once.

This is a full transcript of the video, but you can watch the entire thing below. Have a look at our channel to see the first four episodes from the series and make sure that you subscribe so that you don't miss out on any of our other interviews or tutorials.

Highlights:

Concrete example of a website development with Serverless deployment:

• Integrates with any framework
• You start by creating a /pages directory and define entry points to your application
• Turn each page in the /pages directory into a Serverless function and deploy everything at once by running Now
• You can have part of the website static and another part dynamic. Everything cached on a sort of CDN

Sadek: So, I'm here with Guillermo and for this video, I would like to go through a concrete example of Serverless, and how it would look like, for a developer. We talked about different topics and I want to have all the topics in an example. So, imagine I have an application or a website. Let's say a marketing website. Well obviously, it should be fast, care about SEO, all these kinds of things, and I would like to deploy it on Serverless. How would that look like concretely?

What our platform will do is it'll take the pages directory and it'll turn each on of those into an independent serverless function

Guillermo: Yeah so typically, we integrate with any framework that already exists, whether it's Vue, React, we support and created Next.js. So with Next.js, typically, you start by creating a /pages directory. And inside that /pages directory, you sort of define all your customer facing entry points in your application. Whether it's marketing pages, or login pages. So you could have about.js for your about page or you could have login.js for your login. So the interesting thing is when you deploy it with Serverless, what we have you do is say, "hey I want to use Next.js" So we don't really lock you into a particularly framework. And what our platform will do is it'll take the pages directory and it'll turn each on of those into an independent serverless function. But you don't really change the way you've been writing your application.

The monorepo has this amazing advantage that you always deploy everything at once. And because Serverless makes deployment so fast you don't really need to go around and split up your code into a hundred million places.

And a long side your Next.js code for example, you could define API endpoints, you can define static pages. So it's this idea of what we call the majestic monorepo. It's a monorepo that can contain all of your customer facing logic, for serverless functions, as well as assets and static files as well as APIs. And the monorepo has this amazing advantage that you always deploy everything at once. And because Serverless makes deployment so fast you don't really need to go around and split up your code into a hundred million places. You always just run Now, and you get your URL back. Or you Git push, and we give you your URL for your deployment.

Sadek: But does it change anything if I have to call, for instance, some API for getting the content into the website?

We deploy this to a CDN layer. So if you have static data, we can automatically cache it. If you have something that's more dynamic you can serve it on demand.

Guillermo: No it's just as static or dynamic as you want. And the really cool thing is that we deploy this to a CDN layer. So if you have static data, we can automatically cache it. If you have something that's more dynamic you can serve it on demand. And you can server render for each request. Or you can also piggy back on what we call the cache control API. So you can respond with HTTP headers to cache your content at the edge.

Sadek: Right, so but still this monorepo thing is that you have all the logic. Even if you have endpoints you will be in the same repo.

The monorepo allows you to have components that could be shared between many different pages.

Guillermo: Yeah it's great. And a great example of why this is useful is companies love to have design systems or style guides. So you kind of want to have a coherent set of components for the entire company. And companies don't tend to have only one project. You log in here, and this is the entirety of my company. They tend to want to split up their logic and their teams into sections. Sometimes into different technologies. But at the end of the day when it comes to the customer, you want to see the components and the styles all of the same. So the monorepo allows you to have components that could be shared between many different pages. Sometimes even for example you could have validation rules or Typescript types that are shared between the API and the client side. And you could have all of that always in synchrony. You don't worry about synchronization because it's all in the monorepo.

Sadek: Now there will be people that will tell you, oh are you talking about monolith project? It's dangerous.

Guillermo: Yeah well that's why I always make the distinction between monorepo and monolith. I think monolith you probably don't want. Because monolith just grow infinitely in size. And as we talked about like, without any limit in size, you will become slow. Sooner or later you're gonna become slow. With monorepos remember that we're compiling your code

Sadek: Into different functions.

Guillermo: Into discrete functions and outputs. Which means you can sort of scale endlessly. So the property that differentiates between a monolith and a monorepo, is the fact that functions are independent.

Yeah, so monolith means you're developing a gigantic server. And then typically when people deploy, it becomes a gigantic container. So there is no way around it. But I think, and this is my take obviously, I think people like monoliths because if you're doing a monolith you're always doing a monorepo. So what we're saying is we like the monorepo property. We like that you have one deployment strategy. One command. We like that you Git push and it deploys automatically. And you don't have to synchronize many repos, etc. But what we don't like is a monoliths take forever to instantiate. They're very expensive to run. You typically have to write health checks and monitoring rules. They just become slower overtime.

Sadek: Right. Okay, thank you very much Guillermo for these videos.

Guillermo: Thank you.