peibolsang / octotype

My blogging platform
0 stars 0 forks source link

The Frontend Cloud #7

Open peibolsang opened 1 year ago

peibolsang commented 1 year ago

The landscape of Web dev tech has been oscillating between the "all server" and "all client" models, with each phase presenting its unique set of advantages and challenges. Now, this swinging pendulum is losing momentum and reaching a point of equilibrium (how did I manage to write three Latin words in 1 sentence?). Where's this equilibrium happening? At the center, obviously. Where is the center, though? At the edge

The latest innovations introduced by React-based frameworks such as Next.js and Remix and cloud platforms such as Vercel and Netlify are giving birth to a groundbreaking architectural hybrid model. This architecture is The Frontend Cloud, and it leverages the advancements in Edge Cloud computing and Content Delivery Networks (CDNs) to enhance Web development capabilities significantly. Concretely speaking, The Frontend Cloud leans on the CDN's new computing and storage capabilities, something unimaginable until very recently.

In this post, I will delve into the intricacies of thi model and analyze its potential in reshaping the web development domain.

The Foundation: Edge Runtimes and CDN

Edge Computing and CDNs are at the core of the Frontend Cloud model, which represents a significant departure from traditional cloud infrastructure running in data center regions. Edge computing enables the execution of server-side logic closer to the end-users in geographical edge regions, substantially improving response times and reducing latency.

However, edge the location is less important than edge the runtime when it comes to this idea of the Frontend Cloud. Therefore, most Cloud Computing providers allow developers to run workloads on edge runtimes. These are basically Javascript runtimes, such as V8, Node.js, or Deno. Why is that? Well, there are many reasons, but performance and security are chief among them:

  1. For example, the V8 JavaScript engine supports the concept of "isolates," which are separate instances of the V8 runtime that share no memory or resources with each other. This isolation significantly reduces the risk of cross-script vulnerabilities, data leaks, or unauthorized access to sensitive information.
  2. Running JavaScript in isolated sandboxes allows granular control over resources and permissions. Developers can explicitly define the resources, data, and I/O API access available to each sandbox, limiting the potential impact of security vulnerabilities or breaches
  3. JavaScript is inherently suited for handling event-driven and non-blocking I/O operations, thanks to its asynchronous nature and single-threaded execution model. These characteristics make JavaScript an excellent fit for edge computing scenarios, where efficiently handling multiple concurrent requests is critical to achieving low latency and high performance.
  4. WASM 😇

This ability to perform computations at the edge of the network, coupled with the dynamic content delivery capabilities of CDNs, has contributed to the genesis of the Frontend Cloud model.

Notable platforms like Cloudflare Workers and Vercel Edge Functions have already demonstrated the potential of the Frontend Cloud model with cool features such as HTTP Streaming, which, in combination with React's Supense API and Server Components, are paving the way for the development of lightning-fast, resource-efficient web applications. Moreover, the Edge now supports ephemeral storage through Key-Value (KV) objects, further extending the server-side logic capabilities to run even more complex business logic!

The Limitations of Current Edge Technologies

Despite the numerous advantages of the Frontend Cloud model, we need to be aware of a good number of limitations. One key issue I see is the absence of global replication for KV objects. At present, KV objects are localized to the edge location, restricting their utility for global use cases. However, the introduction of solutions such as Cloudflare's Durable Objects seeks to address this challenge by offering global replication, although the technology is still in its infancy. Overcoming these limitations will be crucial for the widespread adoption of the Frontend Cloud model.

The rapid evolution of Edge Cloud computing and the introduction of the Frontend Cloud architecture suggests that web development will continue to experience remarkable transformations in the coming years. I am very excited about solutions like Redis on the Edge Runtime or even Neon Database, which opens the possibility of performing PostgreSQL read/write operations on the Edge, something that could happen within the next few years. Such advancements would pave the way for the development of web applications with greater flexibility, reliability, and performance.

As the Frontend Cloud model evolves, we can anticipate the creation of new web development tools and technologies that streamline the development process. Real-time data synchronization and adaptive server-side rendering are just a few examples of the innovations that will emerge from this new paradigm. Consequently, web applications will become increasingly versatile, allowing seamless operation across multiple devices and platforms.

Conclusion

Despite the promise of the Frontend Cloud model, several challenges must be addressed before it can achieve its full potential. Latency, data consistency, and security concerns are among the most pressing issues that need to be resolved to ensure the successful adoption of the Frontend Cloud model. As innovators in this emerging field, it is imperative that we collaborate and share our collective knowledge to tackle these challenges and unlock the true potential of the Frontend Cloud.

The Frontend Cloud model, with its unique fusion of server and client-side capabilities, has the potential to revolutionize the web development landscape. By harnessing the power of Edge Cloud and CDNs, web developers can create high-performance, adaptive, and immersive experiences for users across the globe. As the limitations of the current Edge technologies are addressed and overcome, the Frontend Cloud model will continue to mature and reshape the boundaries of web development.

Look at the following piece of code using Next.js and Planetscale:

Ftsg2ipWIBs3Nbd

Looking closely at the code, you may think we are reinventing PHP. However, I like to see this differently. Indeed the server-side code looks like PHP, and the client-side code looks like a SPA. But isn't that the magic? I love how I can combine server efficiency and client reactivity in one app.

peibolsang commented 1 year ago

But there is a catch. What happens if we have a function running on an edge location close to the user (e.g., Madrid's edge location), but the data itself sits in a database running on a distant cloud region (e.g., us-east-1)?

Note: it has to be a database that does not require opening a direct DB connection and instead offers API endpoints for SQL queries, such as DynamoDB, Planetscale, Fauna, or Supabase. Otherwise, traditional database access that require connection drivers is not possible on Edge Runtimes 🤷🏻‍♂️

Enter Regional Edge Functions, a solution that providers like Vercel are introducing. Unlike Global Edge Functions, the regional ones don't run close to the user on an Edge Location; instead, they run close to a cloud region. Even with this architecture, Regional Edge Functions are faster than Global Edge Functions for use cases like the above.

Don't you believe me? Try it out by yourself!

I am sure now you have a couple of questions because the name "Edge Functions" is misleading, especially for the regional ones.

  1. "Aren't those regional functions like AWS Lambda Functions running on a cloud region? what's the difference?". The difference is still performance because even if Regional Edge Functions are similar to AWS Lambda Functions location-wise, they don't suffer from cold starts.
  2. "Okay, what's the difference between Regional Edge Functions and AWS Lambda@Edge". Remember, the location is less important than the runtime. Unfortunately, Lambda@Edge functions still suffer from cold starts, and they offer a very limited API for developers to run meaningful server-side logic for their Web apps.

I got some pictures explaining this from Theo's amazing Youtube video.

Screenshot 2023-04-23 at 14 37 28 Screenshot 2023-04-23 at 14 37 37 Screenshot 2023-04-23 at 14 39 04