How Edge Computing can make the Web better

[peibolsang]

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 or Remix, 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 / Site are generated at build time. It helps build sites, such as information portals or news sites, when data is not changed or updated frequently. Frameworks like Next.js support features such as 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 frequently, it is very large, access latency is critical, or complex processing and transformation are 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 in 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 on the server-side

I believe the discussion and debate around what rendering mechanism is better are conceptually wrong. It may lead you to pick up the wrong framework after all!

The actual tradeoffs and the honest discussion should be around architectural patterns such as JAMstack (i.e., no server-side logic) vs. Fullstack (i.e., server-side logic). When you focus on the architectural style and not the rendering mechanism, you'll see it more clearly as you 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 as 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 platforms, 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 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 edge. That gives you speeds and UX for dynamic Web Apps similar to static sites.

As I wrote in the past, 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 data center from where content originates.

At the edge, client requests and application logic can be processed and executed without sending 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? I think it can make it better, faster, and cheaper with solutions that help and support the Javascript development community. Solutions such as Cloudflare Workers (or Cloudflare Page Functions) are very comfortable for Web developers as they offer the same native Javascript APIs that developers are used to working within 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 in the browser so that 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) 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 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 the 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.
5. Performance: Remember that edge computing providers own cache data centers worldwide, so I am sure there is one close to your location right now. This allows them to 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, 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 will evolve 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 to keep the conversation going!