#What is MercuryCMS?

MercuryCMS is a CMS (content management system) that allows you to design, build, maintain, and host extremely fast, modern websites easily.

Here's an overview of some of its important features and functions:

• Pages and Layouts are designed and dynamically generated based on the Site's data
• Pages are built using custom Components, which group markup, style, and script into reusable custom HTML tags
• Assets and Media are uploaded to the CMS and optimized for use on the web
• The Site's overall settings can be configured, such as where it's hosted, what common tags are needed, etc.
• Custom Collections of data such as Blog Posts, Nav Links, Themes, and Store Items are designed and edited within the CMS
• Collection data is templated into Pages, Components, and even settings to create dynamic Pages and content
• A sophisticated Build system ensures the website loads quickly and is optimized for search engines
• All data is backed up with version history as well as a Trash system to allow for rollbacks if anything goes wrong
• A well designed architecture ensures hosting is simple, extremely fault tolerant, inexpensive, and secure
• Updating site content, adding pages, and even total redesigns are easy due to the power of custom Collections, templating, and staging sites
• Direct access to the site's code allows you to have power and performance without sacrificing flexibility

#How is MercuryCMS Different?

Imagine a typical web page showing a store item. The process for loading this page might look something like this:

• The client requests example.com/store/<itemId>
• The server routes the request to index.php to start the application
• The server loads application configuration and plugins
• The server receives the request and parses the route /store/<itemId>
• The server routes this request to StoreController.php
• The controller queries a MySQL database for information about the store item such as its name, manufacturer, price, and whether it's in stock
• The controller queries another MySQL database for information and configuration about the site such as the site's theme
• The controller loads markup files to template the data in
• The controller generates the page as an HTML response, templating in data and conditionally including or excluding parts that are or aren't needed
• The client receives the response and shows the page
• The client then requests additional scripts that are needed by the page, such as JQuery
• The client further modifies the page's content in the user's browser using JQuery

This is a lot of work to show the store item, and there are a lot of problems with it. What if one or both of the databases are slow, unreachable, or down? What if we need to do maintenance on them? What if the item becomes suddenly popular and we get a flood of traffic? This could bring the entire site down because of this one item. Beyond that, why are we running a server, multiple databases, and a web application to generate the same page over and over?

Here's how MercuryCMS does it:

• The client requests example.com/store/<itemId>
• The closest CDN to the user responds with /store/<itemId>/index.html
• The client receives the response and shows the page

This is a simple example, and doesn't show exactly how we got that index.html file to begin with, but it does show the way MercuryCMS attempts to keep things simple.

#How Does MercuryCMS Work?

The overall idea of MercuryCMS is rather than building pages every time a user requests it, to build every page of the website beforehand and only update it when something changes.

These are the main components used to host a MercuryCMS-powered website:

• CMS used to edit the website
• Database used to store content and configuration
• Build process used to package the website
• Staging server used to view and test the generated website
• Audit step to automatically catch any problems before the site goes live
• CDN used to host all of the production site's content

This setup has a number of advantages:

Any of the upper items can be shut down without affecting the lower ones. Most of the time, only the CDN is active, with all other parts shut down to save costs. When no one uses the CMS for a while, it automatically shuts down until someone attempts to sign into it again.

This also means there is very little attack surface. There is no publicly available CMS for anyone to hack into or database to access as they're not even running.

Because you have a staging website, you can make major changes such as a full site redesign and wait to deploy to production until everything has been tested.

The CDN automatically tracks which content is in high demand and keeps it in memory for fast access making your website perform extremely well.