This document gives an overview on technical concepts of a Frontastic Catwalk. You can read it from top to bottom to gain overall insights or just use it to look up a specific concept. Advice for further reading are given in each section.
Catwalk (and Backstage)
"Catwalk" is the name of the front-end component of Frontastic that faces the end-user. In contrast to that, "Backstage" is the back-end where shop managers define pages, configure layouts and orchestrate APIs.
A project might contain a single, or multiple Catwalks which share code and
contain unique code. For example, it might make sense to create a Catwalk per
germany. Or it could make sense to distinguish
target audiences like:
As a Frontastic developer, Catwalks are your base of working in and with. The following sections explain the concepts you will be working with in scope of a Catwalk.
- @TODO: Directory structure of Catwalk
- Architecture: Catwalk
- @TODO: Calling a Catwalk in the browser
A Tastic is a component that encapsulates visualisation and logic for a front-end puzzle piece in a re-usable way. Shop managers can orchestrate Tastics to be displayed by a Catwalk on various pages in various combinations through configuration in the Backstage.
The following graphic shows examples for Tastics:
As you can see, a Tastic can be very simple (e.g. just a headline) or rather complex (e.g. a product slider). Furthermore, multiple instances of the same Tastic with different configuration can be configured to occur on the same page (e.g. 2x banner Tastic, with different images and 1x with text 1x without).
A Tastic contains:
- A Schema definition (required)
- At least one ReactJS component (required) potentially more
The Schema defines metadata about the Tastic and describes the configuration parameters expected by the top most ReactJS component. The Schema is not used in Catwalk, but in Backstage to describe on a technical level how the Tastic can be integrated. When Backstage configures a Tastic to be used on a certain page, it will ensure that the required configuration is provided.
- How to develop a Tastic
- @TODO Directory structure of Catwalk
- @TODO Schemas
Nodes and Pages
As a Developer, you are not directly concerned with the structure of Nodes and Pages, but you can access and react to them.
Nodes give a tree structure to a Catwalk, similar to sitemaps. The tree is configured by a Shop manager in Backstage. It is typically reflected on the navigation (Tastic). Nodes contain configuration, for example, which streams are available. Every URL that is displayed in Catwalk is rendered on the basis of a Node.
Every Node (in Backstage) can contain an arbitrary number of Pages while only a single Page is active at a time and only the definition of this page is available in Catwalk. To give some context: Shop managers can draft pages before they are made public and they can schedule a time when certain pages should be active.
The Page covers the entire layout visible in the Browser. Pages are therefore structured in Regions and Cells which create a Layout (see below).
Layouts, Cells, Regions (and Kits)
Each Page has an assigned Layout. The Layout defines the top-level structure of the Page in terms of Regions. Examples for Region structures are: "header", "main" and "footer" or "navigation" and "content".
A Cell is a responsive block where the Shop manager can decide if it spreads full width, 1/2, 1/3 or 1/4. The Frontastic CSS framework takes care of wrapping cells automatically. Each cell can contain any number of Tastics. So this is where your work takes place: in a Tastic that resides in a Cell (potentially together with other Tastics), which is part of a Region that is part of a Layout.
Kits don't really matter from a Developer perspective as they are a concept of grouping a number of Cells and Tastics as a re-usable block in Backstage. But before being synchronised to Catwalk, the Kit wrapping is removed.
- @TODO: Graphic to illustrate Layout/Cell/Region/Kit
Your Catwalk resides in an environment which changes when being viewed on different systems. While you develop your code, you test your Tastics in Development. To let a Shop manager test and preview your work you can move it one level up to Staging. Staging is hosted on the Frontastic PAAS and can therefore be viewed from the Internet. Once your work is ready to be viewed by the outside world, you can promote your Tastic to Production.
The promotion of Tastics is done in the Frontastic Backstage Developer App. The workflow of promoting up on environments is also available for Custom Apps and data of such.
Streams are data provides for Tastics. The data provided by Stream originates from an API request to a service that is supported by Frontastic. A Tastic can require to retrieve a certain type of Stream and can interact with it through parameterisation.
Example Stream types are:
- a Product List Stream will contain an array of product objects
- a Content Stream will contain a content object
- a Content Search Stream will contain an array of content objects
A Tastic Schema can include the requirement for any number of Streams that a Tastic requires. At run-time, the Tastic can assume the Stream data is available.
To make Tastics work across different API providers, Streams are abstracted on the server side of the Catwalk. This allows you to re-use Tastics provided by Frontastic for different projects.
A Custom App allows you to provide simple key-value data management facilities to the Shop manager. You just implement a Schema that is very similar to the one used for Tastics. Uploading this Schema to Backstage provides listing and editing facilities to the Shop manager and synchronises this data to your Catwalk.
An example to illustrate this concept: Frontastic comes with a Custom App called Storefinder. With this, the Shop manager can manage point-of-sale stores, their address, contact details and even local spokesperson per shop. In the Catwalk you can now use this data to show users a map of shops, provide contact links and such more.
- @TODO Schemas
- @TODO Development of a Custom App
Replication and Live Preview
Backstage is the SAAS part of the Frontastic solution. This is where all Shop managers edit their data. Catwalks (the PAAS) are entirely independent of this system: Each Catwalk resides in its very own cloud infrastructure and there is no direct communication link from Catwalk to Backstage. This allows each Catwalk to scale independently, to have no performance and failure impact from Backstage.
Still, data needs to be transferred between Backstage and Catwalk. This happens through a component which we call Replicator. The component monitors changes performed in Backstage and transmits these changes in the correct order and a failsafe manner to the Catwalk. Even if Backstage or Replicator fail, the Catwalk stays in tact and works as before. Also, if your Catwalk fails it will not lose any updates because Replication will just continue after the last successful change once the Catwalk is back up.
There is a second, very lightweight communication channel from Backstage to Catwalk: The Live Preview. This channel transmits just a single Node-Page-Combination to be instantly rendered by the Catwalk. As a Developer you do not need to worry about this functionality at all, because your Tastic just resides in the normal environment of Node, Page, Region and Cell.
The following terms are not really important for development in Frontastic, but you may stumble accross them while talking to Shop managers.
A Customer instance in Backstage is called a Project. All of your Catwalks belong to a Project. Catwalks in a Project can share code, data, both and any mixture of that.
Are we missing an important concept in Frontastic that could be explained here? Feel free to hit me an email at email@example.com.