Reference Architectures, 1.0.0
Documentation

Static content delivery

For more general information on how FirstSpirit works, refer to FirstSpirit.

Product description

When performance is key, decoupling the delivery of static content from the generation becomes the ideal solution.

The creation of content in FirstSpirit is based on a "pre-generation" principle. The content is rendered on the FirstSpirit server in a process called "generation". This way it is less time-sensitive and keeps the load of the rendering process off the live system.


Content deployment

In a static content delivery scenario, you have two options:

  • Deployment via S3 and CloudFront
  • Deployment via SFTP module

Deployment via S3 and CloudFront

If you use S3 deployment and CloudFront, all your generated HTML and files like CSS, Client JS, and media files are synced to Amazon S3, deployed via AWS Services S3-Deployment Module, and delivered via CloudFront. CloudFront handles caching for you. You merely have to connect your domain to the CloudFront. Moreover, in this setup, Amazon handles scalability and performance.

The following graph shows the components of FirstSpirit static content delivery using S3 deployment and CloudFront.

Diagram depicting the components of a content delivery system for FirstSpirit CMS, illustrating the process of synchronizing static files like HTML, CSS, and media to Amazon S3, while CloudFront manages the delivery and caching, enhancing scalability and performance.

Deployment via SFTP module

This setup requires you to provide your own webserver. If you choose to use your own webserver, the deployment of files is done via the SFTP module.

The following graph shows the components of FirstSpirit static content delivery using your own webserver.


Security and compliance guidelines

Security and compliance guidelines vary depending on your individual use case. The following provides a selection that should be widely considered.

Decoupled systems offer the advantage that a potential attack or downtime on the webserver does not result in CMS downtime, and content deployment can be directed to an independent system. The webserver is equipped to manage load balancing according to customer requirements.

Conversely, an attack or downtime affecting the CMS only disrupts the editors' workflow without impacting the performance or availability of touchpoints.


References