Part 1: The Challenges of Hosting a Magento Progressive Web App

by | Sep 9, 2020


Andrew hails from the UK, but headed for the warmer Bay Area climate over a decade ago. When he’s not being Webscale’s VP of Marketing, he’s a husband, father, dog walker, wine taster, and hopeless home improver.

The following conversation took place on the eCommerce-Aholic channel, between the show’s host TJ Gamble, CEO of Jamersan, and Jay Smith, Founder and CTO of Webscale. In Part 1, we’ll dig into the key differences between PWAs and conventional applications, especially when it comes to how they are hosted and the user experience they can deliver.

The content has been lightly edited for consistency.

TJ: How different is hosting a PWA to a conventional ecommerce application?

Jay: So, I see this as a bigger topic in terms of how we’re building web applications today, and this transition to what I call more of a micro-services approach, effectively abstracting away the ecommerce application as a whole. In the past, we had a monolithic application which did everything and it rendered HTML. It handled all your backend operations, communications with the database, and outside services, and it was a fairly big, complex piece of code.

Now, what we’re seeing with PWA, and this micro-services transition, is a focus on the individual services that handle single responsibilities within the application. That certainly puts some emphasis on Webscale as the proxy layer in front of that, being able to route and deliver various functionalities from different backend services.

One of the things we’ve added is the ability to route to external services, namely things that aren’t hosted by you. For example, our customers want to manage their user experience from a platform that they own and have control over, but they don’t necessarily want to take responsibility for the shopping cart. So they’ll outsource the shopping cart to Shopify or someone similar. Webscale allows them to bring those pieces together so that the backend application, ie: the shopping cart piece, can be wherever it needs to be in the universe, and it can be purchased as a SaaS offering, and hosted by us, within the context of that application. But it’s only delivering one specific function within the application. Then you have the front end rendering side, whether it’s server-side or client-side, that code is delivered from a different location.

Webscale allows the system to be broken down to its component parts, and acting as a proxy service in front of that, we’re able to bring it all together and present a single URL space to the internet as if nothing had changed.

TJ: In the Magento space, there are really three different PWA scenarios, one being Magento with PWA Studio which is tightly coupled. Theoretically, you might be able to host those in one space. Then you’ve got open-source software with a loosely coupled frontend where maybe they’re hosted in the same space or not. And then you have SaaS backend with a PWA frontend.

In any of those scenarios, for instance with Magento and PWA Studio, would you host those in the exact same hosting? Could I go get a shared host and host Magento with PWA Studio? Or how complicated do I have to get to try to host a tightly coupled PWA like that?

Jay: At Webscale, we’re big believers in single responsibility. So we’ll put Magento in its own cluster and then we’ll put PWA Studio in its own cluster and manage the routing between the two. A lot of what PWA Studio is doing at run time can be accomplished through our Web Controls and the Webscale proxy layer. There we can provide security, routing and control as well as caching and performance improvements, making it all much simpler for the merchant. At that stage, it starts to look more like just a traditional Magento hosting experience.

TJ: Are there any differences if I use SaaS? For example, if I use Shopify or BigCommerce and then build a fully-customized PWA or use some frontend framework, is there a difference when you’re trying to host a PWA versus you being in control of both the pieces?

Jay: There is. The decision that the merchant has to make is whether the client is going to make a direct connection to that SaaS offering, or if it’s going to come back to the origin, and route it to the SaaS offering from there. At Webscale, we have the ability to use an alternate backend that can be a third-party service on the internet. We call this Site Splicing and it allows you to actually hide the fact that your backend is a Shopify shopping cart through the proxy layer with us. What I like about that, is that it allows the merchant to make changes and reconfigure as needed, without having to expose to the internet how they’re choosing to build their application. That’s one of the primary considerations.

This hosting experience is also a bit simpler, because you’re no longer dealing with the requirements of a Magento application, that you have to host as well, and which has its own set of complexities and challenges. You can actually just use somebody else’s service and then focus on the marketing piece or user experience of your application.

TJ: With PWA theoretically, we’re going to push a lot of the processing to the browser. And it’s going to load less data, it’s supposed to be more efficient with data transfer. It’s really focusing on hitting APIs. So theoretically, you should be able to host a site of the same size, if it’s an optimized PWA, for less server resources. But then we’re going to add complexity to our hosting environment, so how are you seeing costs change for merchants in regards to hosting a PWA?

Jay: So on the PWA side, if you shift the complexity into API calls, we’re able to cache more. That’s going to help time to first byte, and the performance of the site itself, which is great. That obviously has an added benefit of reducing the load on the servers delivering the PWA component. These now all look like static assets, and I can cache all of these static assets at the proxy layer, and into the CDN, allowing for a reduction in the delivery expense.

It’s great that we’re shifting most of the execution and the heavy lifting to the browser, because every new user to the site will bring their own compute resources. So, your scaling’s not done on the server side, it’s on the client side, and with more clients comes more compute to service those requests.

The downside is that those compute resources vary in their abilities. It’s not free money. If you have a very complex JavaScript for example, and there’s a lot of code that needs to be executed on the browser, the old iPhone your customer is using is going to get pretty stressed, and your site’s ability to service or provide a great user experience is at risk and somewhat out of your control.

It is becoming more complex. Webscale, as the host, is providing software delivery to the internet, while the developer has to think about where this software is going to be running, in what browser, on what computer hardware, and so on. The emphasis will be on what the user experience is going to be like, on that older generation iPhone versus say a desktop, with the latest and greatest.

Merchants need to make good choices around understanding the capabilities of the device that they’re rendering on and how that device is behaving for them.

Be sure to check back for Part 2, where Jay and TJ will discuss the cost implications of moving to a PWA, from both a hosting and development perspective, and for the full livestream interview, click here.

Recent Posts

Headless Commerce Drives Edge Computing Adoption

Headless Commerce Drives Edge Computing Adoption

In e-commerce today, the challenge to meet and exceed customer expectations is driving innovation. The demand for frictionless shopping, 24/7 availability, superior product and impeccable service quality is ever increasing, putting pressure on...

read more