A core principle of the JAMstack is that sites are not dependent on servers (i.e. origin servers in the traditional sense). Unlike conventional server side rendered sites, sites built on the JAMstack are rendered in advance (pre-request) and served to users directly from a CDN or edge server. Advancements in CDN technology has made it possible for JAMstack sites to run traditionally server side logic like authentication and role based redirects at the edge. In spite of these advancements, modern CDNs are not on par with full fledged origin servers. A notable difference between the two is in their level of configurability.
As opposed to servers that are configurable by the developer to the most minute detail, CDNs are preconfigured by the service provider like Fastly, Netlify and Akamai. Because custom logic available on the CDN is a low level implementation unique to the CDN, developers cannot add further functionality to the CDN. Without an application server or a language runtime, it is simply not possible to run a custom NodeJS, or Python backend on a CDN.
Running a server however doesn't preclude a site from being JAMstack. Sure, you can't run a server directly on the CDN, and rendering a site entirely server side isn't exactly JAMstack-like. But running a server that provides a service via an API perfectly falls within the realm of possibilities on the JAMstack. Often, within the JAMstack model, functionality is outsourced to external services in order to avoid the burden of having to build custom functionality. However, building custom logic for your application and running a separate server for it counts as JAMstack so long as the backend is decoupled from the frontend.
Oldest comments (0)