Magento 2 Extensions For ScandiPWA: Quick Guide

This post presents a project manager-level overview of implementing Magento extensions for ScandiPWA, an open-source PWA theme for Magento. The two main use cases we will be discussing are as follows:

Development of a brand-new extension
Adaptation of an existing Magento extension, such as the one available through the Magento marketplace.

Magento 2 & ScandiPWA setup

Before we proceed with further explanation, let us revisit the main components of an application setup where ScandiPWA frontend is running over a Magento 2.x backend.

On the Magento side, we have a traditional and expected Magento technology stack that normally includes:

PHP / MySQL / REDIS / ELASTICSEARCH
GraphQL layer
Varnish *
NGINX.

Note: The reason we rely on Varnish is that ScandiPWA uses persisted query. Here is how this works:

Every time the application requests data from GraphQL we check if this data has already been served to the frontend before. This is done by checking the request key stored in REDIS. The related key value is a corresponding GraphQL response cached in Varnish. If the response is available, it gets served to the ScandiPWA frontend within 20ms.

Varnish runs as a native Magento integration. This way, whenever changes are introduced in Magento, the outdated version of the cache is automatically invalidated.

On the ScandiPWA side, the tech stack that is downloaded to the visitor’s device looks as follows:

Service workers – proxying all the data to make sure the application doesn’t request the same data twice
React-based single page application
Redux components, containers, routes, styles, etc.

The setup described above is a starting point for any of the further development and extension building. In the following sections, we are going to discuss two different ways to extend it using extensions.

How to add a new Magento extension to ScandiPWA

By design, an extension needs to have both backend functionality (e.g., admin grades, additional product detail fields, category management) and frontend functionality(product fields, labels, customer credit, customer groups, etc.).

The traditional way to present information to the end-user is by rendering the necessary data on the server and passing it as HTML to the browser. This approach doesn’t work in the PWA universe.

Extensions have to integrate both with the frontend and backend. This means that one part of their features and functionality have to “live” on the server, and the other part – on the client-side rendering application.

Since we are dealing with a decoupled system, we need to make a clear distinction:

The server-side part of the application has to be based in the Magento backend.
The client-side part of the application has to be based in the ScandiPWA frontend.

The approach

Backend

First, we have to enable the merchant to manage their backend operations. Thus, on the backend side, we must create an extension, which:

Is managed as a traditional Magento extension
Has GraphQL schema extended with an additional resolver, in order to make the data generated in the backend available for the ScandiPWA frontend.

With these features in place, the backend becomes operational, and GraphQL is now ready to pass the data for display to the end-user. However, the frontend is still not adjusted for the new functionality, and the application won’t be able to request the necessary data from GraphQL.

Frontend

To complete the functionality we need to develop a ScandiPWA extension that will effectively communicate with the backend. Technically, the frontend extension has to address the following:

Request the necessary data from GraphQL
Run Varnish in between frontend and backend
Display accurate and up-to-date information, usually with the help of X-Tags. *

Note 1: X-Tags are used to invalidate user cache data whenever a change in the corresponding data is introduced on the server by the merchant or an update script.

ScandiPWA is currently the only PWA solution that offers the freedom to extend any part of the functionality, as well as the Service Worker. Importantly, this is not achieved via an overwrite, but a full functionality extension.

This type of extendibility is supported since ScandiPWA V.3, with a sufficient body of documentation and tutorials available on the topic.

How to add an already existing Magento extension to ScandiPWA

Imagine a scenario: the extension you are looking for is available via Magento marketplace, it ticks all the functionality boxes and is compatible with your current version of Magento. You are good to install it. The question is, where?

When a traditional Magento extension is installed, it affects both the backend and the regular Magento frontend.

By contrast, PWA projects don’t use the regular Magento frontend, replacing it with a separate React-based SPA.

Still, we need to follow the conventions of headless architecture in order to:

Allow data transfer between ScandiPWA frontend and Magento backend
Let frontend users interact with the server-side part of the extension.

To achieve this an additional compatibility layer has to be created on the frontend.

An important nuance is that the backend extension has to have a GraphQL resolver to properly interact with the frontend. The good news is that it is a common practice among major extension providers to add a GraphQL layer to their products. As a result, the development process is considerably simplified, with all your data pipes readily available for the PWA frontend needs.

ScandiPWA is built to comply with this convention, using GraphQL as an interface to send and receive data.

Using an extension that does not have a GraphQL layer

The same terms apply to all Magento extensions for PWA. In most cases, this means that if a particular extension doesn’t have a GraphQL layer, it has to be added to ensure compatibility with the newly added frontend extension.

Further, the extent to which a specific solution relies on GraphQL to communicate with the PWA frontend depends on the purpose of the extension itself. There are instances where the communication between frontend and backend is minimized, or only needs to happen in a one-way fashion. Examples include:

Payment extensions: These are generally quite heavy on the backend. However, while they allow for multiple configurations, it hardly affects the end-user. The impact of GraphQL is minimized, since the customer simply has to exchange a small amount of data with the server, regardless of the setup.
Advanced reports: This type of extension doesn’t require any interaction with the frontend users, and, consequently, no implementation of the headless architecture is necessary. This makes a GraphQL layer redundant altogether.

Looking to learn more about ScandiPWA? Planning to implement a PWA solution in your next Magento project? Let us help you! Feel free to get in touch: book a free consultation or schedule a call!