## What happened?
Those who know me (or have been following me for a while) know that I love writing. I find it a liberating experience, and it has enormously helped me sort and then consolidate thoughts in my head for years. I am okay with it if no one reads my content; for me, this is more of a _learning in-public_ exercise, and somehow I consider my blog posts as personal rants sometimes! Yes, [I write a lot](https://dev.to/peibolsang), to the extent that I have compiled years' worth of personal notes while I worked on an incredibly challenging cloud product and published them as a book (go check out [Building Software Platforms!](https://leanpub.com/software-platforms))

For a while now, I have been considering running my own blog as an investment in my personal branding. Note that I said "running," not "hosting." As you know, I am a firm believer in SaaS, frontend cloud platforms, serverless, and everything that distills the spirit of treating software as a liability. In part because I am a terribly bad programmer 😇.

I find modern blogging platforms very compelling, but as I said, I wanted to double down on my personal branding without entering into too much development and maintenance costs. It's a sound tradeoff for someone like me, isn't it? [I considered some options in the past using GitHub Gists](https://twitter.com/peibolsang/status/1387894516108103681?s=20&t=GYPC-f0Tt-sr7iSz4dH9lA) but it was [this post from Swyx that really triggered my curiosity](https://twitter.com/swyx/status/1480356418817753088?s=20&t=GYPC-f0Tt-sr7iSz4dH9lA). Yes, using GitHub issues as a CMS and building a small frontend on top sounds like an endeavor I can afford!

## How did I do it?
First of all, being a terribly bad programmer as I am, I wanted to minimize damage and use a stack that maximizes the developer experience. For me, a good developer experience creates spaces for you to focus on fixing the business problem at hand. It's not about magic tools that do hundred of things. That's why the following stack fits the bill for me:

-  **GitHub Issues as CMS** 📚. GitHub's Issue management system gives me all I need to create and manage content behind the scenes. I am very familiar with it, and it's easy to use, widely adopted, and has an out-of-the-box API with a good free tier. It's just perfect!
-  **Next.js with the Blog template** ✍🏻. My new blog site is leaning heavily on this template, and I only added a few new types, components, and UI functionality to fetch data from GitHub through its API, such as issues (as posts), comments, and reactions. Of course, it's a statically generated site, but I have used [Incremental Site Regeneration](https://nextjs.org/docs/basic-features/data-fetching/incremental-static-regeneration), so new issues created in GitHub Issues show up as blog posts after a very short while. It's just perfect and lightning fast. And ISR even works with dynamic paths!
- **Typescript** 💻. I feel very comfortable programming with types. I think it forces you into a kind of healthy DDD thinking and way of programming.
- **Vercel as frontend platform** 🚀. [Nothing to add, you know I am in love with Vercel](https://peibolsang.vercel.app/posts/2)
- **OpenAI** 🤖

Wait, OpenAI? For what? Well, building the whole new site took me about two (2) days. Seriously. It may not sound like a lot to you, but it's a remarkable achievement for someone like me who does not code daily. I have used it extensively to customize the app created from the Next.js template, and ChatGPT helped me immensely to write Tailwind, Typescript, and other Next.js code when I hit a wall. This was one of the main reasons I wanted to build my own site: I felt capable of doing something like this in a reasonable amount of time with this tool. Based on my comments about the developer experience above, I can say that ChatGPT provided me with an **Augmented Developer Experience**.

But there is more. Do you see the post excerpts on the landing page? **I have used [OpenAI API with the text-davinci-003 model](https://beta.openai.com/examples/default-tldr-summary) to generate these summaries of my blog posts and add them as excerpts**. I am just testing this feature, and I believe this is going to work for a while until OpenAI starts to charge me. At that moment, I will probably replace this functionality with a dumb excerpt generator.

## What's next?
I am super happy with the result and super proud of my work (or should I say AI's work?). I think this is a good MVP, but I can think of a few features down the road:

- Better responsiveness for certain pages
- Hashtags and search
- Dark mode
- .... 

And probably nothing else? This is a blog site, so I don't want features creeping over here. I want it to be fast, and I want it to be simple. And so far, this is what I have done. 

I think I'm going to give it a try for a long while!


I created my own blog platform using GitHub Issues as CMS, Next.js and OpenAI in 2 days

## Primitives and Frameworks
We have heard many times that AWS builds primitives, not frameworks. But, what does that mean? For starters, here is my own definition of the terminology:

- **Primitives** are low-level, highly-reusable building blocks with high [Inversion of Control](https://kentcdodds.com/blog/inversion-of-control)​. With primitives, we give developers the power to implement their use cases​ and solve business problems while we don't leave them alone. We present them with added-value tools​ such as UI Components, APIs, or SDKs.

- **Frameworks**, on the contrary, are high-level abstractions that encapsulate concrete and particular use cases. These solutions take longer to build because you are locking down a concrete use case​, even for a concrete persona. That use case is only modifiable via the predicted API of the abstraction you are building, such as smart UI components pre-connected to the backend, low-code tools, or even configurable apps (the highest-level software abstraction possible!)

Are AWS execs really committed to this vision of building primitives only? Of course, they are. After another year of AWS re:Invent, we can see how AWS doubles down on this strategy by introducing new primitives ([AWS VPC Lattice](https://aws.amazon.com/blogs/aws/introducing-vpc-lattice-simplify-networking-for-service-to-service-communication-preview/)) and evolving the existing ones (e.g., [AWS Lambda SnapStart](https://aws.amazon.com/blogs/aws/new-accelerate-your-lambda-functions-with-lambda-snapstart/)), especially around serverless. It looks to me that adding the _serverless_ identifier to an existing service name is a safe path to innovation (and survival) at AWS in this difficult times. I have no other explanation. How else can you say that new services such as [AWS OpenSearch Serverless](https://aws.amazon.com/blogs/aws/preview-amazon-opensearch-serverless-run-search-and-analytics-workloads-without-managing-clusters/) are serverless? This one is far from the first principles of usage-based pricing without minimums.

All this made me think. What happens when all AWS services have a serverless flavor? What's next after serverless?

We can look a this from 2 perspectives.

## A cloud provider perspective
We call _The Cloud_ a set of industrialized infrastructure and computing services offered as commodities you can subscribe to. This definition includes serverless computing, which is nothing but "runtime as a service" where the cloud provider owns the infrastructure and runtimes, and the customer owns the application data and code.

Will AWS (or any other _cloud provider_) ever go up the stack and own the application data and code? No, it's implausible that they enter the SaaS space with out-of-the-box applications, leaving their platform business model behind. As masters of industrialization, I can see AWS in the foreseeable future commoditizing all aspects of modern computing until they reach the highest level of abstraction possible according to its vision. What is this level? Remember, they don't build frameworks, so don't expect them to create new services that lock down specific use cases to help developers build a particular type of application. Instead, they make primitives, so expect new cloud computing services arriving to disruptive fields such as [AI and simulated worlds](https://www.allthingsdistributed.com/2022/12/tech-predictions-for-2023-and-beyond.html), some of them with all kinds of _serverless_ identifiers in their names. Also, expect improved documentation, refined APIs, and better pricing schemes.

In a nutshell, what's next after serverless for them? Nothing, they will keep industrializing computing services. Serverless is the end game for hyperscale cloud providers such as AWS, Google Cloud or Microsoft Azure.

Well, there is one path I believe they would eventually test deeper: the idea of _distributed provisioning with centralized control_. This is about pushing the cloud limits to the edge, where the edge is actually _any_ piece of infrastructure closest to the user, even if that piece is self-managed by them. In other words, this is like transforming your own datacenter in a custom AWS cloud region. We can now say that [AWS ECS Anywhere](https://aws.amazon.com/blogs/containers/introducing-amazon-ecs-anywhere/) was a shy attempt to test these waters, as we didn't see much traction from AWS evolving this family of services.

## A niche player perspective
With all the above, there seems to be a business case for niche players. There is an opportunity now to build frameworks that lock down concrete use cases that solve specific problems for developers when they are building serverless applications. You know, AWS would never do it ... and they should not, [as Jeremy points out in this thread](https://twitter.com/jeremy_daly/status/1474110290874753030?s=20&t=6cM6juM_IoTKCfI43dQILw)!

Okay, but what are these problems? Let me tell you: problem number one is (poor) **serverless development experience**.

One issue that I hear often is that when you are building serverless applications, you don't have a clear view of what services you are using. It's difficult to find your stuff. I've even listened to a few developers claiming that _"with monolithic and serverful architectures, I know all the frameworks and technology I am using just by looking at the project structure in VS Code"_. 

In the early days of serverless, my answer was: _"When you are building a serverless app, that view is provided by the AWS console. You can see all you need there!"_. Almost. Now I reckon my answer was not very satisfactory and those developers still had a point. It's all too scattered in the AWS Console and it is very complicated to track down the AWS services you are using only by looking in there.

The problem is that from a developer's point of view, you don't have a very-much-needed, app-centric view of the serverless services you are using to compose your application. Of course, AWS Console is not the answer, but pointing the developer to lengthy AWS SAM or CloudFormation YAML files is also NOT the answer. That's not the right developer experience.

In a sense, new developer cloud tech such as Terraform and AWS CDK partially alleviated this problem. With Infrastructure as Code scripts, you can now have a dedicated repo of source code that defines and composes your infrastructure. Now, you can see all the services you are using just by looking at the IaC project structure in VS Code! That's a secondary code repo, separated from the main application business code repo, and that's okay. The IaC code repository is just for application composition code, not business logic, and it's good to have them separated. One could argue that the new [AWS Application Composer](https://aws.amazon.com/application-composer/) service introduced at this year's AWS re:Invent visually solves this problem. I have feelings about this service generating YAML code, although I like the idea of deploying your UML collaboration diagram as a serverless app!

So, where is all this heading? What's next after serverless that niche players can help with? It seems that the answer pivots around a better developer experience to build serverless apps, and here's an idea that **new** cloud providers are introducing: Why do you even care about what serverless services you are using to compose your app? What if you let the cloud platform decide what is the best infrastructure needed for your application based on its code?

Enter [Infrastructure FROM Code](https://www.readysetcloud.io/blog/allen.helton/first-impression-of-infrastructure-from-code/). I see an evolution here:

1. **Infrastructure and code**: This is traditional DevOps and IaaS, where operations teams write deployment scripts in chef, puppet, or custom tech to connect users with the infrastructure necessary to run the app.
2. **Infrastructure as code**: This is where where developers can write their own Terraform and AWS CDK scripts to compose the infrastructure necessary for their apps.
3. **Infrastructure from code**: This is where cloud providers transparently provision the infrastructure resources needed to run your applications, so development nor operations teams need to care about it.

## Infrastructure From Code

First of all, let me clarify something. In my opinion, those niche players betting on _Infrastructure from Code_ frameworks qualify as cloud providers. As I said multiple times, you don't need to own a data center and offer your infrastructure and runtimes as a service to be a cloud provider. Instead, evolve and industrialize your services (even if it is pure software) and offer your resources as commodities with sprinkles of self-service, and you also will become a cloud provider.

Okay, what examples of cloud providers fit this definition and offer Infrastructure from Code features? The answer is many already, with players such as [Ampt](https://getampt.com/) and [Shuttle](https://dev.to/ivancernja/infrastructure-from-code-not-as-but-from-5dpg) disrupting the space with purpose-built IfC features and development kits.

However, I have to reckon that [I have a hard bias toward Vercel for multiple reasons](https://dev.to/peibolsang/how-vercel-is-changing-the-cloud-game-fme), the main one being precisely their Infrastructure from Code features designed explicitly for frontend developers building with the Next.js framework. Think about the following potential scenarios if you are building a Next.js app:

- If you are hosting the app on your own infrastructure, it is very likely that after you get your UI bundle with all the assets, you have to put it on a `nextjs` hot server running inside a container ([or inside an AWS Lambda function if you are brave enough](https://stackoverflow.com/questions/58112093/how-to-deploy-next-js-9-to-aws-lambda)). In any case, you need to think about the computing services you need, provision them with Terraform or AWS CDK scripts (if you are using AWS), and get your app deployed.
- However, if you are hosting the app on Vercel, you don't need to think about this. Vercel takes care of the bundle splitting to deploy the respective assets on the right piece of infrastructure. And they do this transparently during the build process, so you don't even care what AWS (or other) serverless services they are using under the hood. They could get the static assets to an AWS S3 bucket, the SSR bits to an AWS Lambda function, and the Edge Functions to another server running on the CDN. In fact, that's what they actually do!

In the case of Vercel, the Infrastructure from Code features are super-powerful for your Next.js app. Because they own both the framework and the platform, they are in a very good position to offer this kind of added-value service, [while others need to run behind catching up all the time!](https://twitter.com/ascorbic/status/1585218371897167872?s=20&t=psF2xsGXoiu5XBJ1NvAvvw).

## Conclusions
It's hard to predict where things might go in terms of cloud development, but one thing remains clear to me: there is an opportunity for startups to bet on serverless development experience. This is something that hyperclouds wouldn't do. This is still an unchartered area where we need definitions and techniques, but this is very likely what the future of native cloud development looks like.

What's next after serverless?

## Introduction

Wait, before you go and pitch your boss on ditching your current setup in favor of serverless without knowing all the details, let's talk about the other player in town first: Kubernetes. Kubernetes (or K8s, as the cool kids call it) has gained a lot of popularity in recent years as a container orchestration platform. It's definitely a powerful tool and has its place in the world of cloud computing. But is it the right fit for your needs?

In this blog post, we're going to compare serverless and Kubernetes and try to answer that question. We'll go over the benefits of both and help you understand when it makes sense to use one over the other. And, just to keep things interesting, we'll even throw in some jokes along the way (because seriously, cloud computing doesn't have to be so serious all the time).

So, let's dive in!

## What is Serverless Computing?

First things first, let's define what we're talking about when we say "serverless computing." Serverless computing is a cloud computing execution model in which the cloud provider dynamically allocates resources to run an application's code in response to incoming requests or events. This means that the developer doesn't have to worry about provisioning or maintaining servers – they can just focus on writing code that runs in response to certain triggers.

One of the main benefits of serverless computing is that it allows for a pay-per-use model. You only pay for the resources consumed while running the code, which can result in significant cost savings compared to traditional cloud computing models (where you pay for resources even when they're not being used). Because in many ways, having a friend with a boat is much better than owning a boat!

Serverless computing also allows for faster deployment and scalability. Since the cloud provider is responsible for managing the underlying infrastructure, it's much easier to deploy and scale applications without having to worry about capacity planning or resource allocation. It's like having your own personal cloud genie – just snap your fingers and boom, your application is deployed and scaling like magic.

## What is Kubernetes?

Now, let's talk about Kubernetes. Kubernetes is an open-source container orchestration platform that was originally developed by Google. It allows you to automate the deployment, scaling, and management of containerized applications.

In a Kubernetes setup, you create "pods" that contain one or more containers. These pods can then be scaled up or down based on the needs of your application. Kubernetes also provides features for load balancing and rolling updates, so you can update your application without any downtime.

## So, What's the Verdict? Serverless or Kubernetes?

Ok, now for the big question: which one is better? As with most things in life, the answer is "it depends." Both serverless and Kubernetes have their own unique benefits and drawbacks, and the right choice will depend on your specific needs and goals.

That being said, there are a few key differences between the two that might help you make your decision.

- **Simplified Architecture**: With serverless computing, the developer doesn't have to worry about the underlying infrastructure or the management of containers. This simplifies the architecture of the application, allowing the developer to focus on writing code that runs in response to certain triggers. Kubernetes, on the other hand, requires a bit more setup and management. You have to worry about creating and scaling pods, as well as monitoring and maintaining the underlying infrastructure.

- **Pay-Per-Use Model**: As we mentioned earlier, serverless computing offers a pay-per-use model, where you only pay for the resources consumed while running the code. This can be a big cost savings compared to traditional cloud computing models. Kubernetes, on the other hand, operates on a more traditional model, where you pay for the resources you use, regardless of whether your code is running or not.

- **Faster Deployment and Scalability**: As we mentioned earlier, serverless computing allows for faster deployment and scalability, as the cloud provider is responsible for managing the underlying infrastructure. Kubernetes also allows for fast deployment and scaling, but you have to manage the underlying infrastructure yourself.

- **Integration with Cloud Services**: Many cloud providers offer a wide range of services that can be easily integrated with serverless applications, such as databases, message queues, and analytics tools. This allows for the creation of highly scalable and performant applications with minimal effort. Kubernetes also allows for integration with various cloud services, but it requires a bit more setup and management.

- **Improved Security**: With serverless computing, the developer doesn't have to worry about patching and updating the underlying infrastructure, as the cloud provider is responsible for this. This can improve the overall security of the application, as it reduces the attack surface and ensures that the infrastructure is always up to date. Kubernetes also offers various security features, but the developer is responsible for managing and maintaining them.

So, as you can see, both serverless and Kubernetes have their own benefits and drawbacks. It's up to you to decide which one is the right fit for your needs.

## But Wait, There's More!

Of course, there's much more to consider when choosing between serverless and Kubernetes. Here are 17 advanced concepts every software engineer should know about serverless

1. **Event-Driven Architecture**: Serverless computing relies on an event-driven architecture, where the code is executed in response to certain triggers, such as incoming HTTP requests, database updates, or the arrival of new data in a message queue. It is important for software engineers to understand how to design and build applications using this architecture, and to be familiar with the various types of triggers that are available.

2. **Function as a Service (FaaS)**: Serverless computing relies on the concept of "functions as a service," or FaaS, where individual pieces of code are executed in response to certain triggers. It is important for software engineers to understand how to write and deploy these functions, and to be familiar with the various frameworks and platforms that are available, such as AWS Lambda, Azure Functions, and Google Cloud Functions.

3. **Cold Start Latency**: One of the challenges of serverless computing is the potential for cold start latency, where it takes longer for a function to execute when it has not been recently used. It is important for software engineers to understand how to minimize this latency, and to be familiar with the various techniques that can be used, such as keeping functions warm or using a higher memory allocation.

4. **Scaling**: With serverless computing, the cloud provider is responsible for scaling the application based on the incoming traffic. It is important for software engineers to understand how this scaling works, and to be familiar with the various tools and techniques that can be used to optimize it.

5. **Monitoring and Debugging**: With serverless computing, the cloud provider is responsible for managing the underlying infrastructure, which can make it more difficult to monitor and debug issues. It is important for software engineers to be familiar with the various tools and techniques that can be used to monitor and debug serverless applications, such as cloud provider logs, APM tools, and debugging tools like AWS X-Ray.

6. **State Management**: With traditional cloud computing, it is easy to store state in a database or on the filesystem of a server. With serverless computing, this becomes more challenging, as the underlying infrastructure is ephemeral and the code is executed in response to certain triggers. It is important for software engineers to understand how to manage state in a serverless environment, and to be familiar with the various options that are available, such as using a database or using a cache like Redis.

7. **Integration with Third-Party Services**: One of the benefits of serverless computing is the ability to easily integrate with a wide range of third-party services, such as databases, message queues, and analytics tools. It is important for software engineers to understand how to integrate these services into a serverless application, and to be familiar with the various APIs and SDKs that are available.

8. **Security**: With serverless computing, the developer does not have to worry about patching and updating the underlying infrastructure, as the cloud provider is responsible for this. However, it is still important for software engineers to understand how to secure a serverless application, and to be familiar with the various best practices and tools that are available, such as using encryption and implementing proper access controls.

9. **Cost Optimization**: One of the benefits of serverless computing is the pay-per-use model, where the developer only pays for the resources consumed while running the code. It is important for software engineers to understand how to optimize costs in a serverless environment, and to be familiar with the various tools and techniques that can be used, such as using reserved instances or optimizing the memory allocation of functions.

10. **CI/CD**: With serverless computing, it is important to have a robust CI/CD pipeline in place to ensure that code is deployed quickly and efficiently. It is important for software engineers to be familiar with the various tools and techniques that can be used to automate the deployment of serverless applications, such as using a deployment platform like AWS CodePipeline or using a serverless framework like Serverless.

11. **Serverless Frameworks**: There are various frameworks available that can help software engineers build and deploy serverless applications more easily. These frameworks typically provide a set of tools and libraries that can be used to define and deploy functions, as well as handle tasks like scaling, monitoring, and deployment. Some examples of popular serverless frameworks include AWS SAM, Serverless, and OpenFaaS.

12. **Event-Driven Data Processing**: Serverless computing is well-suited for event-driven data processing, where data is processed in real-time as it is generated. It is important for software engineers to understand how to design and build applications that can handle this type of data processing, and to be familiar with the various tools and techniques that can be used, such as using a message queue or a stream processing platform like Apache Kafka or AWS Kinesis.

13. **Microservices**: Serverless computing is often used to build microservices architectures, where an application is composed of multiple independent services that communicate with each other using APIs. It is important for software engineers to understand how to design and build microservices using serverless computing, and to be familiar with the various tools and techniques that can be used to manage and deploy these services.

14. **Integration with Server-Based Applications**: While serverless computing is well-suited for building cloud-native applications, it can also be used to integrate with existing server-based applications. It is important for software engineers to understand how to integrate serverless functions with these types of applications, and to be familiar with the various tools and techniques that can be used, such as using a reverse proxy or an API gateway.

15. **Hybrid Architectures**: It is possible to build hybrid architectures that combine serverless computing with traditional cloud computing or on-premises infrastructure. It is important for software engineers to understand how to design and build these types of architectures, and to be familiar with the various tools and techniques that can be used to manage and deploy them.

16. **Serverless Patterns**: There are various patterns and best practices that have been developed for building serverless applications. It is important for software engineers to be familiar with these patterns, and to understand how to apply them to different types of projects. Some examples of common serverless patterns include the Fan-Out pattern, the Command Query Responsibility Segregation (CQRS) pattern, and the Event Sourcing pattern.

17. **Serverless Limitations**: While serverless computing has many benefits, it is not a panacea and there are certain limitations that software engineers should be aware of. It is important to understand when it is appropriate to use serverless computing, and to be familiar with the various trade-offs and limitations that come with it, such as cold start latency and the potential for vendor lock-in.

## Conclusion

So, there you have it – a comparison of serverless and Kubernetes. As we mentioned earlier, the right choice will depend on your specific needs and goals. Both serverless and Kubernetes have their own unique benefits and drawbacks, and it's up to you to decide which one is the best fit for your project.

We hope this blog post has helped you understand the differences between serverless and Kubernetes, and has given you a better idea of which one is right for you. Remember, there's no one-size-fits-all solution when it comes to cloud computing, and it's important to consider the pros and cons of each option before making a decision.

But hey, don't stress too much about it. After all, we're just talking about cloud computing – it's not like anyone's life is on the line here. Just do your due diligence and choose the option that makes the most sense for your project. Happy cloud computing!



Why I favor serverless over kubernetes

## Different rendering options

It appears to me that making architectural decisions for Web development is more complicated than ever due to the emergence of frameworks that bake in client/server tradeoffs. Yes, I am thinking of [Next.js](https://nextjs.org/) or [Remix](https://remix.run/), which offer different rendering options for different use cases. In any case, there is a lot of information out there to help Web developers make informed decisions.

Typically, Web developers solve these tradeoffs and pick one rendering method or another driven by a combination of data and user experience requirements:

- **Static Site Generation (SSG)**: Pages of your Web App / Web Site are generated at build time. It helps build sites when data is not changed or updated frequently, such as information portals or news sites. Frameworks like Next.js support features such as [Incremental Static Regeneration](https://nextjs.org/docs/basic-features/data-fetching/incremental-static-regeneration) which means that the static site is regenerated **on the server** automatically based on a schedule configured by developers.

- **Server-Side Rendering (SSR)**: Content of your Web App / Web Site is generated dynamically on a request basis. This rendering solution is most appropriate for data-intensive scenarios where content is updated very frequently, it is very large, access latency is critical, or complex processing and transformation is needed before returning the response to the client.

- **Client-Side Rendering (CSR)**: The data displayed on your Web App / Web Site is served through an HTTP API and rendered by the client on the browser. To improve the performance time at the client device, this data must be lightweight and ready to be consumed without further processing. This approach can help for those cases where user interactions and state management of the user interface need to happen as close to the user as possible to offer a very interactive and reactive user experience.

However, modern deployment options have additional non-functional requirements (NFRs). I am talking about NFRs such as an extra twist in performance, cost implications, and environmental impact. These are things that nowadays Web Developers need to consider when making these architectural decisions.

## The battle at the server-side

I believe the discussion and debate around what rendering mechanism is better is conceptually wrong. It may lead you to pick up the wrong framework after all!

The actual tradeoffs and the real discussion should be around architectural patterns such as JAMstack (i.e., no server-side logic) vs Fullstack (i.e., server-side logic). When you put the focus on the architectural style and not the rendering mechanism, you'll see it more clearly as you will look at the problem from a more accurate prism. At the end of the day, you can do SSR with JAMstack but it just happens at build time! Also, you can do SSG with Fullstack if you play with the `stale-while-revalidate` cache header like Remix does.

Why are Web development teams shifting to the server side again? The answer is because of the commoditization of infrastructure and **serverless**. It is now easier than ever to have backend computing for your Web applications and sites.

>"_Higher-order systems create new sources of value_" - Simon Wardley

We now count on an extensive catalog of managed cloud services and pure serverless primitives. There is a battle in this server-side space between second-tier cloud platforms such as Vercel or Netlify (they don't own Datacenters) and first-tier cloud ones such as Cloudflare and AWS (they own Datacenters). They all compete with each other to offer the best Web developer experience and optimize those new NFRs. 

Especially for first-tier cloud platform, this battle is making innovations spring at a pace we have never been before, especially with the emergence of **Edge Computing** solutions.

JAMstack was introduced as a _workaround_ under certain infrastructural assumptions, advocating for the separation of server-side stuff from pure Web development for performance and UX reasons. The world has changed, and Edge Computing is breaking those initial assumptions!

I mean, you don't need full round trips to the cloud region to obtain data. You can now serve it from the CDN, or even run pieces of logic on the edge. That gives you speeds and UX for dynamic Web Apps that are similar to static sites.

[As I wrote in the past](https://dev.to/peibolsang/the-future-of-cloud-computing-is-developer-experience-g0p), computing at the edge is not about CDNs and caches anymore; this is something else. We are now talking about moving part of our applications and services to an edge location. An edge location is where cloud providers cache content so that it can be very quickly accessed by local referrers. It also allows local access to the cloud platform's network backbone avoiding the public internet between the edge location and the regional datacenter from where content originates.

At the edge, actual client requests and application logic can be processed and executed without the need to send that request to a service running on the origin cloud region. Of course, this approach still qualifies as serverless because you don't need to provision or manage any type of runtime. Additionally, this approach comes with further benefits, such as global distribution and automatic multi-region access for your applications out of the box.

## Edge Computing use cases

Okay, then, how does edge computing help Web development? In my opinion, it can make it better, faster, and cheaper with solutions that help and support the Javascript development community. Solutions such as [Cloudflare Workers](https://workers.cloudflare.com/) (or [Cloudflare Page Functions](https://developers.cloudflare.com/pages/platform/functions)) are very confortable for Web developers as they offer the same native Javascript APIs that developers are used to work with in the browser. It's a very natural ecosystem for them.

In its current form, I would choose Edge Computing services only as an add-on layer on top of my server-side components running at the cloud origin for very concrete use cases:

1. **Data Filtering**: Filter data coming from the application components before sending a response to the client. This can be done based on user-specific criteria such as location or device type. The goal is to avoid data processing and filtering as much as possible at the browser, so it can receive ready-to-render data.
2. **Stateful Requests**: Combined with lightweight storage at the edge (e.g., Key-Value stores), we could handle sophisticated states on edge on top of the application running on a serverless environment. And we could do it without firing full round trips to the cloud origin region. This would allow Web developers to build session-based online collaboration tools (e.g., Miro dashboard) running on serverless computing.
3. **Authorization**: Apply Role Based Access Control rules to UI components returned to the client. Imagine you are including an Admin section in your UI which options are affected by the user's role. Filtering those UI options at the edge would be a very cost-effective and high-performant solution.
4. **Cyber-protection**: Use native cybersecurity features and APIs at the CDN to identify networking patterns such as bot detection and apply URL redirects to avoid exposing the application code running at cloud region to malicious agents. Also, I've seen edge functions used to prevent _clickjacking_ or _XSS_ attacks by [adding security headers to the response](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/example-function-add-security-headers.html).
5. **Performance**: Remember that edge computing providers own cache datacenters all over the world, so I am sure there is one close to your location right now. This allow them implement powerful caching mechanisms to improve TTFB for static content (HTML, CSS, Javascript bundles) and other techniques such as image resizing optimization based on user devices. 

## Conclusion

These use cases can be game-changing especially for Javascript developers building Web applications. Solutions like Cloudflare Workers are based on [Google's V8 engine](https://v8.dev/) allowing response times for client requests under 50ms (i.e., full round-trip, not just internal execution time). Then, as described above, the main logic for the server-side components would run entirely on the cloud region, with a preference for serverless components. But who knows, maybe edge computing evolves to the point where we can run larger pieces of business logic closer to the user location.

I am getting my hands dirty with a few of Cloudflare's solutions right now, so in my next post I will cover in detail a few of their most compelling edge computing services. Follow me on [Twitter](https://twitter.com/peibolsang) to keep the conversation going!

Pablo Bermejo.

A tech blog using GitHub Issues as CMS

Featured Story

I created my own blog platform using GitHub Issues as CMS, Next.js and OpenAI in 2 days

What happened?

More Stories

What's next after serverless?

Primitives and Frameworks

Why I favor serverless over kubernetes

Introduction

Modern Web Development with the Modern Cloud

Different rendering options

How Vercel is Changing the Cloud Game

1. What is Vercel?