Progressive Web Apps (PWAs) are making their way into mainstream, and Magento agencies have been increasingly striving to adopt the technology in recent years. The reason is digital merchants and customers alike choose to implement it - motivated by desire to benefit from the next-level features it provides.
One of the more viable PWA solutions available on the market today is ScandiPWA - a dedicated PWA theme for Magento. It is ready-made, it runs out-of-the-box, it is SEO-friendly, and it is engineered to enhance performance and drive conversion.
PWA adoption rate among Magento merchants is at its highest today. The trend is showing no sign of slowing down, but other than obvious performance benefits, the technology brings along the need for React development. And this has been a major pain point for many in the business.
Some of the reasons include
Whichever way the working process ends up being organised, an experienced agency understands that for an effective development, its various elements must play well together: mainly front-end and back-end, as well as the corresponding teams.
Let’s take a look at the core elements of an effective PWA / Magento development.
Front-end: reactive applications aka. reactive front-end
With this setup, a common data travel pattern looks the following way:
In the context of a so-called default Magento shop, this flow is supported by ScandiPWA out of the box. It provides functionality assuring data transport and data exchange between application and GraphQL server, including Redis, where we store queries, and Varnish, where we store responses to these queries.
However, real-life projects rarely stay within default margins. And it’s not just the existing features and layouts that need to be customised. Anyone working closely with Magento, knows that it is a common practice to have custom elements tailored for a specific purpose. Depending on the task, you may need to introduce new data entries, data variables, data types etc., in your database. Magento is great for this, allowing what is known as “extreme customisation”, or as they call it themselves - “unprecedented flexibility for user experience”.
Inevitably then, all the changes taking place on either front-end or back-end, need to be effectively propagated between the two instances. You need to make sure that the data travels correctly, that it is cached efficiently, and that various data scenarios are handled.
Another layer of complication for Magento agencies is tied to organising the project workflow. They want to employ a React team on the front-end and a Magento team on the back-end, but they are not willing to delay the project, because it is challenging to have both teams work simultaneously, as opposed to taking turns. This usually becomes even more difficult when a React team is working remotely.
Sometimes, a client will be really into PWA driven by improving user experience, which means that there is also a high demand for a tool for building quick interactive prototypes.
The risks that need to be handled in the process may include:
So, the question that occurs in the light of all that’s been said is - How to enable both front-end and back-end teams to work efficiently individually, and later successfully merge their efforts in a beautifully performing PWA project?
Our proposed solution is twofold. Depending on the specific implementation, we suggest using either End-to-end simulation or App-based simulation. We are now going to look at both of these techniques and explain how they can benefit your project, and what you need to take into account for an effective implementation.
This method is used when a back-end team is working on introducing changes on the Magento side, and we want to simulate the expected result on the front-end. The simulation takes place on the level of GraphQL server. Specifically, we need to create a resolver, detached from Magento database, that will request the necessary data points from Redux and provide data according to the request.
End-to-end simulation involves front-end team setting up Magento with Magento-based GraphQL server. This allows to run ahead of time and simulate the responses before the the actual mechanisms to provide these responses are created, tested and implemented. This type of simulation can be useful for prototyping, as it allows to showcase to the customer different layouts and different page compositions based on different inputs.
Let’s take a look at the technicality of decoupling front-end and back-end by simulating responses on the level of GraphQL server.
Delivery can be validated based on the initially agreed data structure and sample data. This helps to adhere to the contract, because we can define the delivery and contract terms, providing description of data structure, data samples and data scenarios, as well as specifying how they are expected to behave on the front-end.
Another important ingredient is evaluating the ways the expected data scenarios are reflected in the design. Assessing both data structure and design interactivity provides means to evaluate the delivery.
Finally, once the Magento team is done with their work on the back-end, we are ready to override the hard-coded resolver with the real data. And if something doesn’t work, we have the flexibility to bring back the mock data, debug and compare the mock data with the actual GraphQL responses from the server to find what caused the problem.
End-to-end is considered more beneficial in the long run. Specifically, it is a good fit for an agency if they are requesting a theme as a deliverable from an external team. This way, it’s easy for them to define expectations and the contract.
With an app-based simulation, the front-end team can work completely detached from Magento. They don’t need the GraphQL server, except for the basic tasks - such as to make sure the application runs, or to make sure the navigation patterns are correct (e.g., are we on a category page or PDP?). However, some modules and components can be developed without this connection.
From the diagram we see that, while some changes may be taking place on the Magento back-end, the front-end and GraphQL server remain unchanged.
What happens is we use affordance to change fetch query to mock query. In practical terms, it means that you don’t change arguments. Rather, when a mock query is processed, the response is read from the mock registry, instead of executing a request.
Finally, once you are happy with the result, and your back-end team tells you that they are expecting the response to be correct - you can change mock query back to fetch, without changing the arguments.
On the code level, you need to replace fetch query with mock query, while keeping the same arguments. Then, a mock query registry has to be created for containing data that needs to be fetched. The data from the registry can be fetched either by URL, type or tag, although tags need to be processed with caution, because the arguments we are passing will not be consistent between mock and fetch when we switch.
When the back-end part is ready, we need to replace mock with fetch and see the result. We may encounter additional complexity if the front-end and back-end teams are detached. In this case, the team that receives the theme as a deliverable will need to look for components for mock query and figure out which ones need to be changed.
App-based simulation is applicable if an agency wants the teams to collaborate closely, e.g., if front-end and back-end are developed by on-site teams within the agency.
It relies on both front-end and back-end teams discussing the data schema and being up-to-date regarding what is going on with the data scenarios. When both back-end, and front-end rendering are ready, the mock query on the front-end can be changed to fetch, and the project can be debugged by both teams. And if both parties belong to the same team, then the resulting feature is delivered as a joint effort.
This type of simulation doesn’t allow to easily limit the contract, if the teams are detached, unless you devise and agree on specific detailed testing scenarios.
Data schema is king. It acts as a common ground for front-end and back-end teams, and assures that the developed project is operational.
Data scenarios are crucial to help understand how data schema behaves under different circumstances, such as receiving expected/unexpected data, too much, too little or no data.
Scenario simulation level has to be chosen based on the project details and team availability:
Hand-over format needs to be defined. If it is a delivery of a full feature, we want to delegate theme development to a React team/agency. Here, things to take into consideration are:
There should be a clear integration process, defining how the deliverable will be incorporated in the rest of the project.