--
/
--
Table of Contents
1. OVERVIEW
2. END-TO-END SIMULATION
3. APP-BASED SIMULATION
4. ENDNOTES
/
--
PROBLEM OUTLINE
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
PWA introduces a tech stack that is often alien to a normal Magento agency
The tech stack has a certain learning curve:
It is not just another version of PHP
It is not something you can master in a few hours
PWA introduces a different workflow:
Data travel is different
Client-side rendering has certain idiosyncrasies
Agencies that consider hiring React developers, are often faced with additional
choices to make:
Finding and hiring a remote team specialising in React development
Their work needs to be further organised and merged with that of the in-house
Magento back-end developer team.
OVERVIEW
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.
/
--
core elements
Back-end: Magento
Magento database
Magento backend
GraphQL server - recently introduced as a part of Magento installation
Front-end: reactive applications aka. reactive front-end
VIEW components, responsible for component presentation
React container, serving as a connector to Redux, and holding the BFE (back-of-
frontend), aka. the business-logic
Redux, managing global state (the state of React component is an array/inventory
of data that is currently up to date for a particular component. Redux also allows
to control the state of the entire application, letting you to see who is updating
the data, when and how)
With this setup, a common data travel pattern looks the following way:
data travel
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. /
--
the demand
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
The risks that need to be handled in the process may include:
New features introduced in the theme don’t work when applied to Magento instance
Data doesn't travel between front-end and back-end
Data is hardcoded on the component view layer
Front-end is unable to handle different data scenarios, e.g., if
Data is presented in a wrong format,
Data is missing, etc.
the big question
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
--
END-TO-END SIMULATION
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.
the approach
Let’s take a look at the technicality of decoupling front-end and back-end by
simulating responses on the level of GraphQL server.
First of all, we need to agree on the data structure and GraphQL schema with
back-end developers. Then, as we are ready to decouple front-end and back-end
teams, the first step is to have an agreement regarding the ways to merge both
teams’ results. The common denominator in this process is data schema.
The GraphQL schema is converted and hard-coded as a response on the
GraphQL server. And if we need to change anything, we change the response
manually.
Once the database/back-end part is completed, we override the hard-coded
resolver, and start providing the real data.
/
--
Good thing is that no changes to the theme are necessary. The React VIEW
components, React container, Redux - are working with the GraphQL resolver as if
they were communicating with the actual back-end. In reality, we are creating a
dedicated module, that is replying with hard-coded data - a string of JSON.
Then, as we switch back to receiving responses from Magento, we can expect to
see the planned result on PWA front-end.
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.
the usage
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.
/
--
APP-BASED SIMULATION
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.
the approach
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.
the usage
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.
/
--
ENDNOTES
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:
App-level, using fetch & mock queries.
Server-level, using GraphQL server to mock a Magento module on the level of
GraphQL resolver.
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:
What is the format you expect from them?
What is the validation mechanism? How do you evaluate the quality/scope of the
deliverable?
There should be a clear integration process, defining how the deliverable will be
incorporated in the rest of the project.
/
About Us
React, GraphQL & Redux knowledge is #1
necessity for any Magento developer in
the next 2 years. Scandiweb has been
React / PWA industry forerunners, and the
fact that it is being pushed forward by
prominent brands like Netflix, Whatsapp,
and NY Times inspires even more
confidence in our choice.
With the largest in-house eCommerce
development team in Europe and the US,
Scandiweb has been delivering world-class
digital solutions for 15+ years.
We offer speedy solutions and round-the-
clock support for clients all across the
globe, specifically focusing on bespoke
React & Magento PWA projects.
LEARN MORE
