Pros + Cons of JavaScript Servers, Serverless, and Cloudflare Workers

Episode Summary

Executive Summary: The episode compares three approaches to running server-side JavaScript: traditional Linux-hosted Node servers, serverless functions, and Cloudflare Workers. The hosts explain the operational trade-offs, where the code should live, and when each model makes sense. Their main conclusion: keep most business logic in reusable library code and keep request/response handling thin so it can move across platforms with minimal changes.

Main Topics: Traditional Linux-hosted Node servers: Discusses the classic model of running Express/Fastify/Node on a managed Linux box, including direct server control, disk access, and the operational burden of updates, SSL, and scaling. Serverless functions: Explains how serverless routes and functions execute only when invoked, offering pay-for-use pricing and easier hosting, but with limits around startup, long-running tasks, and dependency size. Cloudflare Workers: Covers Cloudflare Workers as a distinct edge/serverless environment with a non-Node runtime and stricter package compatibility, but strong performance and deployment appeal. Code organization for portability: Advises keeping most application logic in a shared library layer and isolating only request/response wiring in framework-specific handlers to ease migration across platforms. Operational trade-offs and scaling: Compares ease of management, caching, session storage, logging, and scaling across the three hosting models, emphasizing that complexity increases as infrastructure control increases. Choosing the right platform by use case: The hosts recommend selecting a platform based on app shape: simple APIs and hobby projects fit serverless well, while stable business systems may be cheaper and easier on traditional servers.

Key Arguments: Most backend code should be platform-agnostic business logic in a lib folder, with only thin request/response adapters in the API layer. Traditional servers offer full control and are straightforward conceptually, but you must handle updates, SSL, disk, scaling, and server maintenance yourself. Serverless is ideal for sporadic or small workloads because you pay only when functions run, making low-traffic APIs cheap or free to operate. Serverless functions are less suitable for long-running processes, persistent connections, or packages that depend on native Node/Linux features. Cloudflare Workers are appealing for performance and edge placement, but their runtime compatibility is narrower than Node, so package selection can be painful. The best architecture depends on the project; the answer is not universal, and the same core code can often be adapted across hosting models.

Data Points: Free credit from Linode: $100 - Promotional offer mentioned for trying Linode hosting. Cloudflare Workers package compatibility claim: 20,000 packages - Cloudflare is described as saying many NPM packages work with Workers. Cloudflare Workers compatibility examples shown: 55 packages - The hosts note Cloudflare only highlighted a small set of example compatible packages. Traditional business hosting cost: a couple hundred bucks a year - Wes says his course/business platforms run on traditionally hosted Linux servers at this cost. Serverless warm state: 15 minutes - Serverless functions are described as staying warm briefly before sleeping again. Example response time limit: 50 milliseconds or less - Mentioned as a constraint some serverless environments expect for work execution.

Pivotal Quotes: "80% of your work is actually done in the middle" — Wes: Explaining that business logic should be separated from framework-specific request/response code. "You only pay for the time that they are actually doing work" — Wes: Describing the economic advantage of serverless functions. "The answer is it depends, as always." — Scott/Wes: Final takeaway on choosing between traditional servers, serverless, and Workers.

Implications: Developers should design backend logic for portability and choose hosting based on workload shape, operational tolerance, and cost. Serverless and edge options lower entry friction, but traditional servers still offer predictability and compatibility for fuller applications.