Self-referencing Page Rendering Makes All Route Patterns Possible

Here is the most important part of Viking CMS. It is self-talking.

This is because while it renders HTML on-board, it does so exclusively from content coming from arbitrary data feeds. Most of these are coming from the server itself, but it requests them from itself via HTTP. This means that we don't need to have fancy controllers supporting a thousand different views. All we have to do is maintain a certain number of data feeds within the system. Here is what the data feeds for our "/home" page looks like in the "page editor" for example:

This is an example from the 'home' page on this site. Note that these feeds are internal, relatively referenced instead of absolute reference. This sends the request back through the server itself, as another process, and they occur concurrently. Our platform is Node.js based, and it is very easy to make these sorts of asynchronous requests in that language. When the "/home" page is rendered, each of those feeds is requested in parallel (concurrently), from the servers themselves. It happens in a heartbeat.

Even more importantly, we can use path patterns to use parameters from the requested URL, such as the story :id, in our request for our data feed. This is what makes the story page possible. Obviously, we don't want the same content for each story URL, we want that single, unique story. This method means that not only do we have that story, we can also have any other content that you want to build a feed for. We've seen things like "relatedStoriesWithVideos", "mostPopular", and even things like outside forecasts or any outside data. It's all handled exactly the same.

Here's an example of what a path pattern is doing, on this very page, the "story page":

This is the route of the page in the page editor:

The ":id" and ":slug" become useful parameters that can be passed to the page template, and used within arbitrary data feeds. In the case of this URL, on the page you just requested are:

1. :id => 67f1c58e722966662557e493
2. :slug => self-referencing-page-rendering-makes-all-route-patterns-possible

During the event of page rendering, these values are passed on to the arbitrary date feeds at the bottom of the page template. Up to 20 are possible for an individual page. In this page's case those feeds are:

You see how the "story" object depends on an arbitrary route as well?

1. This means that ":id" (67f1c58e722966662557e493) now gets used in that "feed" URL, or any feed like it, of any structure.
2. That means for this story URL, the data feed fetched to render this page is "/feed/story/67f1c58e722966662557e493", or for any story like it.

In one swift motion we created a framework for an arbitrary site-structure!

Once those feeds are fetched, they are used in the story page template like this:

That's the complete story page template right there. The whole thing. That's what you are looking at now. Most importantly, it's written as EJS which is an extension of raw HTML. Your on-site designers can change it at-will, instantly. When they update it, all story pages like it update instantly. When I say instantly, I mean that the change is proactively sent to all CDN nodes the moment the button is pushed. Instantly.

This also considers the tags and as well. In the case of arbitrary feed-based routes, that metadata will bubble up from the data feed. To understand what's happening there, look at my list (for this site) of pages:

If you leave the "title" and/or "meta" blank, it will automatically fill in content from the dynamic feed data for that route! Our self-referencing protocol means that we can server-render any content that you have a feed for, ours, or anything else you want. It also means that your route structure is NOT something we determine, it's what you determine. You aren't stuck with our particular list of features. Most CMS will offer something like a "story" route and a "category" route, but we offer any route of this sort you could want, in any structure you can dream up.

Here is a cool example from one of our customers, who wanted to have a route based on a date:

This would have been a big development task for any other CMS, that would have needed to be deployed to all customers. Viking CMS makes this a task that can be done in-house! This cuts down the amount of front-end work, deployment cycles, and it also wildly improves CLS scores and initial page render speeds. It's pretty fancy!