Before we dive headfirst into Development, it's essential to understand our Architecture.
As mentioned in the First Time Users section, Backstage is the Software-as-a-Service component of Frontastic. As a Developer, you can upload Tastic specifications, Custom App specifications, monitor and profile your code in production, and much more.
Let's firstly look at a simplified version of our Architecture:
Straight away, you'll notice that the Delivery and the Editor are decoupled applications and they're maintained that way. This means that if the Editor goes down for any reason, your Delivery (and website) will still run smoothly for you and your customers. Also, if another customer's Delivery goes down, yours will also be unaffected.
Sarah, the Frontend Manager, edits the website in the Frontastic Editor. This data is copied to the Delivery using the Replicator to keep the systems decoupled. When a visitor browses the website, a call is made to the Delivery and it displays all the information the Frontend Manager has created in the Editor while calling the Data APIs to fill all the Tastics with the data that's been configured also in the Editor. Sarah can also preview the pages she's made and that uses the same calls to the Delivery.
The Data APIs are entirely separate from the Frontastic Infrastructure as we don't store any data. That's why we're the head to your headless system. All the data for your products, content, accounts, etc., are all stored within your headless system, we just display them as you've configured it and we don't store the data in between. So if Sarah configures a Tastic to only show Sunglasses from the 2020 collection in ascending price order, the Editor doesn't know what the exact products are in this list, but when the website user navigates to where that Tastic is on the website, the call to Delivery will provide the product data from the Data APIs and then display it to the user in the way it was configured in the Editor.
You may notice the arrow going from Replicator to the Editor, this represents the requests that the Replicator makes to the Editor. The job of the Replicator is to constantly check if there are any changes in the Editor and if it finds any, it will pull this data and push it to the Delivery.
Let's go another step deeper to look at how the architecture looks from a Developer perspective:
Take a look at the systems under Delivery on the right of the image above. Delivery is basically a website framework and on top of that, there’s the Progressive Web App (PWA) running React Redux as well as pattern library facilities using Storybook.
So what we deliver to you is a Source Code base that contains the Delivery and you can implement your own Source Code right beside that in order to create your visual experience. All of which is done within your own GitHub repository.
You can also attach your own custom backends, you can just write your own controllers, your own API integrations, and so on and we'll deploy that to our Google Infrastructure.
And let's go one step deeper again:
This version of our Architecture shows how in some cases, you can work entirely locally. We then provide Deployment and Continuous Integration through the Cloud Platform.
Whenever there’s a successful build on the Master branch of your repository, we'll automatically create a new instance group in your staging system and playout a new image for that instance group. When you decide that your build is ready to be deployed to Production, you can do this easily in the Editor.
As you may have noticed, we mention Tastics quite a lot and that's because Tastics are the central element of Frontastic. As a Developer, one of your roles will be uploading Tastics to the Editor as well as plugging it together in the Delivery so it can then pull the data from the Data APIs of your headless system.
A Tastic is made up of a definition from the Editor, the corresponding frontend code which is in the Delivery, and the required data from the Data API.
A Tastic always consists of two parts:
- A JSON file which defines which data the Tastic requires and how this should be configurable in the Editor, we call this JSON file the Tastic Schema
The Tastic Schema needs to reside in the Editor before it can be placed on any Page.
For each Tastic, the configuration can be different but will always follow the Developer's specification from the Tastic Schema. Once a Page is stored and made public in the Editor, it's automatically transferred to all relevant Deliveries. This includes your local development environment where you always have the most recent version of every Page available for testing.
If a web browser is pointed to a URL on the Delivery where the configured Page should be served, Frontastic creates an instance of the JSX component of the Tastic and automatically fills in the data that is defined by the Tastic Schema.
So, in a large number of cases, you won't have to worry about how to get hold of the data you need in your frontend components but Frontastic will ship it to you.
Let's look at how that works:
Now you know the systems and how they're connected, let's look at the request flow.
The backend of Delivery is responsible for handling the initial serving of the PWA code as well as all subsequent data requests when the Website User changes the view. The process is similar for both cases:
- The browser requests a certain URL
- Frontastic will determine which Page should be displayed
- It loads the data for all Tastics on that page as defined by the Tastic Developer and configured by the Frontend Manager in the Editor
This includes pure configuration values from the Editor but also fetching information from the attached API providers.
- The collected Page structure information, configuration values, and API data is transferred to the PWA in the browser
- Frontastic expresses all the JSX components for every Tastic on the Page to display and provides it with the requested information
- Actions by the Website User will result in a new request with either a complete or partial data update
On the very first request from a Website User there are a few more steps happening:
Instead of just returning the structure and data to the browser as JSON, a very slim HTML template is also returned. This will make the browser load the actual SPA code and take over the rendering in the browser. If required, Servers Side Rendering (SSR) will take place to pre-fill the HTML body for SEO and browser performance reasons.
Let's look at how that works:
Our technology stack consists of community proven applications, tools, frameworks, and components as shown below:
In the frontend, we mainly use ReactJS + React-Router. For metadata and SEO requirements we have React-Helmet included.
For the development and build toolstack we use Yarn, webpack, Babel, and Storybook plus a variety of additional smaller tools on top of these.
In order to provide a common CLI experience across all tools, to define a build pipeline, and use this also in Continuous Integration (CI), we're using Ant. Ansible is our tool of choice for provisioning any server environment and automating everything around Frontastic.
In an ideal frontend world, you wouldn't need to touch the backend at all. While this can be a reality for many Frontastic projects, there are many cases where you will need to adjust or extend the backend functionality. So, we've made the Frontastic backend highly extensible in multiple ways:
The most used extension point is an API Lifecycle Decorator, with this you can hook into any of the API calls that Frontastic issues and manipulate the input or adjust/enhance the output. For example, you could change searches by adding more parameters, enhance product information through data from additional API service or hook into cart value calculation as an item is added to the cart.
The backend that serves Delivery is a very slim and fast application based on Nginx (as web server) and Supervisord (for long-running processes) is in place. Both work mostly with PHP (cutting edge version) scripts.
Symfony 4.x and Doctrine form the basis for our backend. Composer and PHPUnit are the most significant development tools here.
As the Catwalk data storage, MySQL is used. Frontastic has chosen these long term established solution stack due to its stability, scalability, and fault resilience.
The code in Delivery accesses Cloud APIs for data retrieval, data manipulation, and workflow. For example, a Delivery will interact with a commerce API like commercetools or ABOUT YOU CLOUD. These APIs will provide product data and search facilities but also basket and checkout management facilities to the Delivery.
Frontastic accesses these APIs behind a common API layer to ease switching between different API providers, to allow the development of frontend components that work against all supported backends, and to encapsulate authentication.
Custom Backend Services
Please note that such services can't be hosted and supported by Frontastic. However, since microservices should be slim and simple, hosting them on any available Cloud Platform should be possible with very little effort. If you want to host such microservices, take a look at Heroku.
‹ Back to Article List