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 / 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 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
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.
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 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 (or Cloudflare Page 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:
- 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.
- 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.
- 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.
- 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.
- 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 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 to keep the conversation going!
(Cover photo credits: Alan Tang via Unsplash)
Top comments (0)