Our Experience With a Magento PWA Project

If you are reading this article, you (should) already know what a progressive web app (PWA) is. However, let me just summarize the main benefits:

• PWAs are a lot faster than the classic Magento storefront. This positively impacts SEO efforts, conversion rate, cart abandonment rate, retention rate and percentage of return customers.
• It’s 3-in-1: a website + iOS app + Android app. Basically, you develop the website and display an “Add to Home” button on the homepage or wherever. Users who click on this button will end up with the app icon on their home screen and the app installed on their phone. The app is the website, but with no browser interface. You can even install it on Windows if you want. 
• Push notifications. Once users add the app to their computer, you can dispatch push notifications to their phones, for example with sale promotions.
• Offline browsing. You can still browse through the website while you are in area with no internet available. Depending on the implementation, you can also place orders. Information needs to be cached first in the browser, subject to some limits.

There are obviously other benefits, but four are easier to memorize.

PWA Technologies

PWAs on Magento are basically a JS-based (React, Vue, etc.) storefront, which replaces the classic Magento storefront. The pages are built on the fly in the browser using JS components and GraphQL data queries. GraphQL is a query language using JSON-like syntax, returning JSON results, which are subsequently inserted in the JS-constructed interface. The back end is still the familiar Magento admin interface.

It’s what you would call a client-server architecture. If you know what client-server is, you are close to (or past) retirement. Since pages are not put together at the server level, everything is extremely fast compared to the classic Magento experience, especially after information is cached. Note that I said “information is cached,” because what is cached here is data rather than pages. The platform we use (ScandiPWA) caches queries with Redis and their responses with Varnish. Pages are a shell, populated in a flash with raw data from the cache or database.

The Current State and Future of PWA on Magento

Magento announced PWA Studio, a set of PWA tools, a few years ago and released it to the public in 2018. PWA Studio is not a ready-made theme or front-end interface. However, there is something that could be used as a starting point: the Venia theme, also developed by Magento as proof of concept. Venia is still in its infancy — I would say it is not production-ready — and it has its share of quirks, one of them being the innovative yet atypical checkout. But it’s getting better.

Magento adds additional GraphQL endpoints with each new Magento release, making it easier for anyone interested to develop a PWA website. Not all features of the Magento storefront have GraphQL coverage, but hey, you can learn GraphQL and develop your own endpoints — or wait until Magento attains 100% GraphQL coverage. 

Magento is progressing slowly with PWA, but they also have the merit of igniting the movement. Speaking of which:

• There are already several companies that already developed their own PWA storefront. Among them are Simicart with a headless storefront built on React, ScandiPWA with a PWA theme, also React-based, Divante with Vue Storefront (headless based on Vue.js), and an increasing number of others. 
• Major extension developers like Amasty have already started building PWA front-end add-ons for some of their best-selling extensions and adding GraphQL endpoints for other extensions. Extension developer moved extremely quickly with rewriting their Magento 1 extensions for Magento 2, and so they will PWA, especially because it’s a smaller effort.

The future has PWA written all over it. To paraphrase André Malraux, Magento 3 will be PWA or it won’t be at all.

Our PWA Project

Back in 2019, we were approached by a client, a large company with a well-established e-commerce presence. They wanted to replatform their website to Magento 2, and they mentioned several times they were interested in also building mobile app companions for their e-commerce store, especially since over 80% of their traffic was mobile.

This was a particularly difficult project, even for classic Magento 2. It had been developed originally on a custom platform (platform developed by us as well, before our company switched to Magento). On top of that:

• The site had been heavily customized. In eight years, hundreds of feature customizations were added so that the platform would fit like a glove to the client’s business.
• There were three language versions, with specific payment and shipping methods, delivery estimates, etc.
• A deep ERP integration, with complex flows of information between the two systems.
• A content-heavy company-oriented section, which we eventually had to develop on Wordpress. Some information in the e-commerce site (product question and answers) needed to be transported (automatically via an integration) to the Wordpress site and vice versa.
• Complex data migration. All the content had to be moved to the new site: product information, orders, customers, reviews, Q&As, blog articles, and a hundred or so pages that could only be migrated by copy and paste (and reformatting).

The project was a biggie. We designed over 80 screens, while we normally design 20-30 screens for a typical Magento project.

Challenges

This project definitely took us way out of our comfort zone. I would compare it with our transition in 2016 from M1 to M2. There was a huge difference though: at that time, we started the easiest project possible, while now we had to replatform a very complex project.

Here are some of the technical hurdles we faced:

• Classic Magento 2 extensions didn’t work (mostly). To be frank, we expected that even before starting the project, it was obvious that we had to build our own front end for all front-end-facing extensions. So, basic features like better sorting, integrations with payment gateways, better reviews, product Q&A, free gift, gift card, SEO-improving extensions, etc., which normally are plug-n-play, were not, in our case. This amounted to many hundreds of hours (probably more than 1000) spent on creating React components for those extensions. 
• Frequent PWA updates. The PWA platform evolved rapidly during development (that’s good), but it blocked some of our teammates who needed to update the code. The last update, for example, which was a cumulative update (we postponed about two months’ worth of updates) took us two weeks to apply, test and fix.
• Some customizations were difficult due to Magento’s intricate architecture. We had to change how Magento natively works in Cart and Checkout, areas that are normally complex and difficult to modify without ramifications.
• Issues with Magento’s GraphQL implementation. The PWA platform used some or most of the existing GraphQL layer. Some of the critical GraphQL queries were badly implemented and broke the layered navigation by not refreshing the attribute values after selecting options, which in turn led to frequent and annoying “no products in this category” messages. Or, in one case, products with multiple select attributes where multiple values were selected in admin were hidden in the front end. Some of these issues were fixed by the PWA platform providers, some we had to fix ourselves.
• Basic integrations with Google Analytics and Google Analytics Ecommerce, which normally can be done in a matter of minutes with classic Magento, were a pain in the proverbial backside with PWA. Should I also mention we also had to implement Google Enhanced Ecommerce and Google Pixel events?
• SSR. That’s short for Server-side Rendering, and it’s a must if you need to reduce the impact of the transition to your SERP ranking. Although Google says “we can crawl PWAs, because we invented them,” the crawling process is slower (in two waves) and uncertain. Google Search Console is not yet able to render PWA pages properly with a Live test (formerly known as “Fetch as Google”); that’s why I would not skip the SSR step. There are several ways of implementing SSR, so you are not left without options on this

PWA Platform

We chose ScandiPWA because their PWA looked a lot more mature than Venia and because the people ScandiWeb appeared to treat this project as a serious contender for Magento’s own PWA. It’s a theme rather than based on a headless architecture, but that to me is a minor aspect.

We had other options as well (for example Vue Storefront), but we settled on ScandiPWA, and so far I don’t regret it. They released version 3 a few months ago, which is an extension-ready theme, and there is also an extension Marketplace, including extensions and add-ons like RMA, special promotions pro, gift cards, blog, product labels, social login, store locator, Stripe and PayPal payments, Google Tag Manager. The updates are frequent, and there is support and communication available (via Slack, Medium and a forum).

Skill Stack

We have specialized roles for back end and front end work and avoid “full-stack.” Most of our projects are on the complex side, heavily customized, with complex requirements and flows, so we need people with deep knowledge of how Magento works. The typical Magento project involves at least one to three BE Magento developers, one to three FE Magento developers, a project manager (or even two in some cases), one to two QA, a designer, an SEO consultant and e-commerce CRO specialist (both on-demand, when needed), and a content specialist (for data migration in its many forms).

Our PWA project came with a few twists:

• Magento FE developers needed to acquire and improve React and GraphQL practical knowledge.
• We brought in already skilled React developers (sadly with no Magento knowledge, but it worked to some degree).
• We found there are two kinds of React developers: those who deal mostly with UI, and a second type who are kind of back end for front end.
• Magento BE developers needed to learn how to build GraphQL queries and understand how the PWA data flows work.

Organizational Challenges

• We had to involve two project managers, both for redundancy reasons and because the complexity of the project required it.
• The project required an unusual amount of daily communication. We had a daily meeting each morning, which used to take 30-60 minutes. Normally, daily one-hour meetings are a huge waste of time, but in this case we wouldn’t have been able to pull through otherwise. We had to deal with the complexity of the requirements, combined with technical complexity inherent to projects where over 30% of the technology is new to the team. The entire team had to participate, but we would remove participants during the meeting when their presence was no longer needed.
• Front-end developers lead the way. They transform the design mockups into React components, while defining the structure of the GraphQL queries and responses for each component. This structure is then used by back-end developers. There was some degree of back and forth involved for each task, the typical task being reassigned between the front end and back end several times before completion.
• QA entered later in the project. We never leave testing for the end of the project; QA work is tightly interwoven with programming. We normally test each screen (e.g., Home, Category, Product Detail, etc.) as soon it’s implemented. We tried, as usual, to involve QA testers early in the project, but it was difficult. So many features did not work properly in the first two months of the project that testing was totally useless. We had a rapidly growing list of known issues, and developers were aware of what needed to be fixed. QA testers had to still participate in all meetings in order to stay familiar with the project.
• Costs and time were a moving target. As with any complex project, fixed price should be a no-no.

Conclusion

Pioneering new technologies is always painful. It’s difficult, time-consuming and costly but has the benefit of moving you to the next level. We have a history of moving (cautiously) from a technology stack to another. We started in 2002 with ASP.NET and our own CMS, then in 2011 we switched to LAMP and open source in less than 12 months, while at a time starting to develop exclusively responsive e-commerce sites.

The next big changes where in 2012 (when we chose Magento as our e-commerce platform), then in 2016 (when we developed our first Magento 2 site). Magento 1.x died in December 2016 for us as a platform for new sites; we developed all subsequent sites on Magento 2 exclusively.

I now feel the same with PWA. It’s the next logical step after Magento 2. PWA is the future of e-commerce. I don’t remember having said that about another technology, with all those changes we went through.

Would we implement a new PWA again? Bring it on!