SHCDAS: Static and Dynamic Content Delivery

This blog post is part of the SaaS Headless Content Delivery Architectures Series (SHCDAS).

A web server can respond to an HTTPS request with a static resource, such as the contents of a file or database record, or the web server can invoke an application service platform to generate content dynamically. Application service platforms include anything that can invoke CMS HTTPS endpoints that return JSON, such as .NET, Java, JavaScript, PHP, Ruby, and so forth.

Because clients such as browsers provide JavaScript and other technologies, both static and dynamic content delivery can generate equally dynamic websites. The difference is that static content delivery does not allow logic on the web server while generating response output such as HTML. For a static website, all logic is encapsulated in JavaScript and HTTPS services.

Static content delivery refers to those resources that the content delivery tier can serve without application services. In a completely static content delivery solution, every page URL corresponds to a file under the document root of the website or in the Content Management vendor’s Content Delivery Network for media, especially for media. JavaScript in served pages may include dynamic logic, such as to retrieve additional data from the CMS, invoke search, experience management, and other services managed by the customer and third parties, and otherwise provide dynamic visitor experiences.

Static solutions are relatively simple to conceptualize, build, and administer. Separation of content and presentation from services can improve manageability. The entire site can be cached on a CDN, so solutions can perform very well, allowing low-cost scalability.

Dynamic content delivery extends static content delivery in that any application server can respond to an HTTPS request with a static file. In addition, dynamic content delivery allows logic while servicing each HTTP request rather than simply serving the contents of a file. URLs on the site may correspond to files that contain instructions to run on the server to generate unique output in response to each request. The main drawbacks of dynamic content delivery is the need to maintain application servers that can be difficult to scale.

With dynamic content delivery, developers typically edit application server code files, although it is possible for the build process to generate files that the application server interprets as code to execute. Rather than specifying paths or service URLs, URLs in dynamic solutions may correspond to data endpoints that run instructions such as processing files in locations completely unrelated to the path in the requested URL.