An application architecture describes the patterns and techniques used to design and build an application. The architecture gives you a roadmap and best practices to follow when building an application so that you end up with a well-structured app.
It also shares other important features in the architecture patterns:
Client-Side-Rendered (CSR) - an architecture where the view logic is run in the browser. Such applications may only be written in JavaScript (or a language that compiles JavaScript). What are the advantages of Client-Side Rendering?
Single Page Application (SPA) - An SPA (single-page application) is an application that dynamically renders web pages in the browser. Typically, an SPA is completely rendered on the client side. ScandiPWA uses the React library to achieve this functionality.
Progressive Web Application (PWA) - an application that complies with a specific set of requirements. These requirements include a ServiceWorker presence and web manifest.
What is a ServiceWorker?
A ServiceWorker is a programmable proxy. It installs between a browser and a server. It proxies all network requests and may intercept any. This is helpful for implementing offline features or data caching.
What is a web manifest?
A manifest is used to specify configurations to be used by an operating system in order to define an appearance of an installed application. These configurations include icon appearance, theme, splash-screen, and application name. Once installed, PWA is available from the home screen of your native device at any moment.
Mosaic Architecture - is an architecture that implies the use of standalone modules for application arrangement and application themes. This makes possible:
File overrides - Override files from the parent theme.
Plugin mechanism - Extend existing functionalities without changing the original code.
In a conventional Magento, all of the pages are generated on the server. This means that the client needs to fetch the entire page every time the user clicks on a link, and even with caching enabled, the pages need to be fully re-generated whenever part of the relevant data is modified. Not only does this make Magento resource-hungry, but it results in slow load time.
Instead of rendering the pages on the server and fetching them every time, ScandiPWA only fetches the data from the server, and performs the rendering on the client-side, using React. The page is never actually reloaded - once the app’s JavaScript code has been loaded, the front-end magic happens without any help from a server. This provides several advantages:
Improved Performance
Now that the rendering happens on the client, the server does not need to render the entire page every time. It merely needs to serve the data required by the client, which can happen much faster.
Smooth Transitions
Since the client is responsible for rendering the page, it knows the structure of the page even before requesting the data. As a result, we can implement a smooth transition to the next page, and display placeholder loaders until the data arrives.
First, review a schema that depicts the complete architecture of ScandiPWA:
They can be grouped by:
With orange, the path to a rendered React component is marked. Along the way, starting from React(What is React?), we encounter the initialization of Redux Provider(What is Redux provider?) and React Router (What is React Router?). There are a few other players in the orange line:
<aside>
➡️ The Router component is responsible for what is rendered on a page.
</aside>
React component is a UI template file. In ScandiPWA it is used solely for rendering.
<aside>
➡️ UI templates are located in files with the .component prefix
</aside>
Logic Container - If there is a UI template, there should also be a place to write some business logic (non-rendering logic). Another React Component is responsible for that, but it is used as a Higher-Order-Component, wrapping around the UI template. ScandiPWA calls this file a container.
<aside>
➡️ This logic is located in files with the .container prefix
</aside>
Redux props mapper - maps the Logic Container to a Redux store. Basically allows making a connection of specific business logic to a global shared state. (How to connect a component to the global state?).
<aside>
➡️ This logic is located in files with the .container prefix
</aside>
The data in the ScandiPWA application is always coming from the GraphQL API. There are two important players who help to construct this flow:
Request utility - a set of default utility functions that allow to make GraphQL queries or mutation requests.
<aside>
➡️ This logic is located in the Util/Request file
</aside>
GraphQL queries - a defined set of GraphQL query documents, that utilizes the Util/Query library to dynamically generate clean and extensible GraphQL queries using JavaScript.
<aside>
➡️ This logic is located in files with the .query prefix
</aside>
<aside> ⚠️ To make requests in ScandiPWA, it is necessary to have a valid query/mutation defined in Magento to return the necessary data.
</aside>
Requests are generally made from Logic Container (What is Logic Container?) or Action Dispatchers (What are action dispatchers?).
Updating or accessing a state, regardless of its location, can be as simple as calling a function. ScandiPWA uses Redux to make this possible.
Redux introduces:
ScandiPWA also uses dispatcher functions. Dispatchers are used when the data necessary to update the state is not available.
The Redux state can be updated using either a dispatcher function or by dispatching an action directly. The method you choose depends on the specific update you want to perform:
<aside> ⚠️ Dispatch an action and dispatcher functions are different things!
</aside>
consolidating proxy logic