PWA

Deploying a Magento PWA project

Why PWA might be the future of headless eCommerce

Progressive Web Apps (PWAs) are designed to address the mobile revenue gap indicated below.

In most markets, online retail has a higher proportional audience reach among mobile users than desktop. However, mobile sales numbers are much lower. There can be many reasons for this, some in the realm of technology.

At one time it was thought mobile engagement was best achieved using an app. This was based on data for mobile users in general, but was possibly skewed towards gaming and social media. An app has advantages of being able to deliver notifications, use mobile features the way a typically website cannot, be installed as an icon resulting in easier access.

On the flip side, there is data suggesting mobile users were reluctant to install apps due to issues like memory limitations. Other disadvantages include a need for an OK from Apple to be on the app store, lack of easy-to-test infrastructure, the rather slow process of distributing updates – for example some users may not have auto update on.

Using service worker technology, widely supported by browsers today, the PWA (or progressive web application) will give some of the benefits of an app without the cost of consuming memory, requiring an OK from Apple and being as easy to deploy new updates as it is to update a website. PWAs are also as easy to test as a website. A PWA will install on a mobile as an icon – much like an app, service workers allow push notifications as well local storage, allowing for some offline capabilities.

From a technology perspective PWAs pose a completely different problem – the relative newness of technology means developers are limited, as are systems to reliably host & deploy. The cost of development will come down as more developers and websites adopt the technology.

Hosting related issues with PWA for Magento

From a hosting and code deployment perspective. Vue-storefront for example, replicates the entire catalog in elasticsearch and uses 2 nodejs processes to run the frontend of the store. PWA Studio is expected to be Magento (read php) native, yet the reference implementation of its Upward Specifcation Is in nodejs. Both developer and production environments pose challenges.

Developer Environment

It is no more a localhost WAMP stack that you can deploy and get a development environment for PWA setup. A single project will require setup of various components (vue-storefront, vue-storefront-api, Magento, graphql, elasticsearch, redis, rabbitmq, etc).

The developer environment will affect the learning curve of the many new developers starting with these new technologies as well as the productivity of experienced developers.

Here are some challenges

  1. Launch a development environment for a new project
  2. Setup a developer environment for an existing project
  3. An ability to change and test any component easily – for example if a js file was modified that affects the UI, what component(s) need be redeployed? Can this process be automated?

It is too early for us to start work on solutions for developers – since we do not do project work ourselves. However, we are working with our partners and we have an eye on releasing a “developer stack”. Contact us if you would be interested.

Production Environment

We recently took a PWA website live. Developed by our partner Codilar, it was a first for us. Some of the challenges faced and lessons learnt are summarized below.

  1. Setting up a production environment.
    Since there were so many components, not natively supported by Magento, many configuration files had to be manually modified.

    1. Vue-storefront (the UI end that replaces varnish in a classic Magento 2) needs to communicate to Redis for Full Page Cache and the vue-storefont-api
    2. Vue-storefront-api communicates with elasticsearch and Magento 2 backend via a rest API. Ideally vue-storefront should replicate the entire catalog through a indexing process into elasticsearch, but that is not fully operational yet.
    3. Magento 2 has its own redis cache and redis session. Magento 2 FPC is not used. Magento 2.3 uses RabbitMQ in addition to connection to its database.
      Here is our architecture for the deployment. We used Virtual machines as shown. We did not use a containerised architecture. The reasons will possibly be a different blog post.
  1. Starting nodejs processes automatically. Vue-storefront uses pm2 for process management. However, developer information and documentation is written using yarn to run the pm2 processes with log files being stored in ~/.pm2. In order for better control from a system administration perspective, we installed pm2 at the global level, generated systemd files (using pm2 startup) and modified them to suit the environment. We can now use “service vue-storefront start/stop/restart”.
  2. Monitoring all the components.
    Log files for each component are taken to a central log processing server using CNCF project fluentd.
    A key challenge is observability of failures. A Magento 2 API failure is not obvious. An error return code from vue-storefront needs to be traced to vue-storefront-api to Magento. Correlating the actual hit that caused a non-fatal Magento error is another challenge.
  3. How to deploy new code with minimum or even 0 downtime
    For Magento 2, until a database change is required (via a bin/magento setup:upgrade and/or indexing), we have a process to make a deployable package, giving an opportunity to deploy with 0-downtime. Check out our bitbucket pipeline presentation.
  4. How can one deploy a vue-storefront based PWA?
    The project we migrated ran on 2 git repos – one for Magento, the other for vue. Upon deploy we need to find the files that changed since the last release and decide if the change is in Magento, vue-storefront or vue-storefront-api and decide the build steps appropriately. Presently since the repos are different, we have 2 separate builds running on the production servers. A pipeline based deploy is our next step.

Note: We think a monorepo for both Magento and vue is essential in the long run due to possibility of versioning incompatibilities.

Conclusion

This is yet early work-in-progress and we hope to update our process and keep updating this article as we go.

PWA in Magento – how do your images look?

Progressive Web Apps (PWA) in Magento opens a new opportunity to improve image quality on eCommerce websites. Use of good quality images has been known for a long time to be the a key factor in digital experience and hence conversions. In recent years many factors have changed that requires a relook at how images are served. These factors include :

  • Shoppers increasingly use mobile devices for eCommerce
  • The vast improvement in the ability of mobile devices to show high quality images
  • Improvement in the mobile internet connectivity speeds with 4G and above
  • Improvement in compression formats with introduction of webp
  • Advancement in responsive UI technology ranging from HTML picture tag and srcset attribute to PWAs that increase the application awareness of the ability of the mobile device

Through PWAs in particular, the app knows enough of the device to decide what pixel ratio as well as width of the image to get, thereby improving displayed image quality to the best possible.

PWA in Magento is now live. To see a curated list of modern eCommerce sites see https://headless.page/.

Analyzing www.hartsofstur.com for image quality

I picked a magento site and analysed for image quality. The site is the beautifully made. The site looks like a standard magento website – except that on click, the page does not seem to refresh (though the address bar changes URL) – only the content does. That is nicely done.

This site is a PWA created using Deity Falcon – a headless open source library built with ReactJS, NodeJS and GraphQL.

The Category Page

When you navigate to a category listing page from the menu, the category view uses API to get details including images.

The API URL for a category looks like this https://www.hartsofstur.com/api/catalog/products/57. (A real URL has layered navigation and other filters appended).

Such a URL returns category information as json. Let us review a snippet below :

See the “thumnail_url” (3 lines below the highlight) in the json is a standard Magento image URL from the cache. The image comes from this API for each element. The thumbnail URL is not device aware as no hint of the device was passed to the category API.

The website seems to return the same image URL (image size 600×600) for any sized device as shown below.

600×600 image is resized to 165×165 in html

600×600 image is resized to 250×250 in html

Device Pixel Ratios


Using higher Device Pixel Ratios, todays mobile phones give a very high quality image display experience to users. HTML tags have been enhanced to allow their usage. However, many eCommerce sites do not use such features.

No CDN

The other notable hosting of this website is that it does not use a CDN. Use of CDN is every more important for PWAs.

Developing PWA for Magento?

Talk to us about how our hosting stack which includes a image generator, can improve the quality of images you display.

Here is how our stack compares with default Magento for image generation.

  Magento luroConnect
When is an image generated? Pre 2.3, synchronous with frontend

2.3, synchronous with product save

Asynchronous – queued on product save
Webp support No support Supported – needs img tag change
High resolution 2x, 3x, Retina display Possible with img tag change – but makes synchronous problem worse Possible with img tag change – asynchronously generated
Other image optimizations Not possible In the roadmap
such as progressive jpeg

During the demo we will show you how the luroConnect stack can help your website.

  • Improve the quality of images displayed on your website.
  • Block any malacious hits to the site
  • Divert admin traffic to another server
  • Show what a Disaster Recovery Plan can do
  • See site performance on a dashboard
  • Review your current server size and suggest improvements to gain performance and/or reduce costs of hosting (a $100 value)