Do you need Node on the server to run Magento PWA Studio?

You need Node on the server to run Magento PWA Studio

So let me start by saying this: You need Node on the server to run Magento PWA Studio. No, I'm kidding. The answer is more complicated. It requires more effort to get to the right answer. The real answer should be: Yes and no, it depends. And most importantly, maybe, you can host Magento PWA Studio without requiring Node, thanks to the Magento UPWARD module written in PHP. Or maybe that's just a silly workaround. Ha ha ha, I'm having a ball here.

Maybe the question itself is wrong. You can run PWA Studio both with Node and without Node. A better question is maybe: Why would you need Node on the server in the first place? What benefits does it give? As always, we need to dive into the details before you can answer the question properly.

The PWA of Magento PWA Studio

Let's dive into the stack first. I often explain that the product suite that Magento labels as Magento PWA Studio is composed out of three words: Magento, PWA and Studio. Magento being the creator, PWA being the thing that we are building, Studio as a means to build it. If we are saying that we are running Magento PWA Studio somewhere, it is actually a wrong statement: You run only the Studio in development by means to produce a PWA and that PWA is then pushed towards production.

PWA Studio offers various tools to help you develop your own PWA based on React: There is a collection of UI components in the Venia UI library. The Venia Concept theme allows you to quickly put things together. The Peregrine library offers some more fundaments. Buildpack offers a Webpack-based development environment, including a local Node server. And last but not least, there is UPWARD, which is something that even James Zetlen can't explain. I'm still having a ball here.

The UPWARD part is quite essential in this blog though. Let's get to that point later.

What is the end result?

Talking about all of those different tools within a PWA development environment like PWA Studio, it could lead to confusion on what the end result is. However, it is simple. The end result is an HTML document with JavaScript, CSS and images.

Now, the end result of a regular Magento frontend (like with Luma) is also just an HTML document with JavaScript, CSS and images. So this appears to be leading to the same result. However, the HTML document with PWA is structured in a radically different way: Instead of the HTML document forming the main portion of the website, the HTML document of a PWA is reduced to a skeleton. And on top of that skeleton, JavaScript is loaded - maybe in the form of React - which not only speeds up the entire webpage, but also allows for various progressive features (the P of PWA).

It sounds kind of simple, right? However, this blog is not necessarily for the newbies. I assume you know what PWA stands for and that you grasp what kind of opportunities it gives you. The point is to simplify something that is often seen as quite complex: The dynamic nature of a PWA simply boils down to a regular webpage.

How to get data via JavaScript?

Once that PWA is there, being a clever combination of HTML, CSS and JavaScript, we'll still need data to be loaded from the server. In the case of Magento, that's accomplished via AJAX calls towards GraphQL and REST endpoints. Instead of just using any AJAX client, we'll want caching, throttling and lazy-loading in there as well, which is why PWA Studio has choosen for a combination of React and Apollo Client. But it is still just AJAX. You could build it yourself with a simple Node fetch as well.

As long as JavaScript works in the browser, this new Magento PWA frontend works just fine: Results are actually received faster than with a normal Magento frontend. And all content is there as well. People are happy.

Deploying a PWA to production

So what do you need in production for this to work? The answer is: File uploading. No PHP, no Node, nothing. Just upload the static files to the cheapest hosting environment possible and you're done. Obviously, you still need a Magento environment, but that's a different story. The PWA is only a bunch of files, with content interpreted by the JavaScript engine of the browser.

It becomes a bit more complex when you also want to host the PWA on the same domain as Magento. It makes it easier to cope with other issues like SSL certificates and cross-domain scripting. But it also requires a clever setup of the webserver (Nginx or Apache) to decide which files to resolve when: PWA files or Magento files. I'm intending to write a blog on this soon, because such an Nginx configuration is actually dead-simple.

Moving on.

What is UPWARD?

With the right setup, you even do not need the Magento UPWARD module within Magento to run Magento PWA Studio: You can simply modify a couple of lines in the PWAs src/index.js file so that UPWARD is bypassed for GraphQL calls to Magento. And static files are resolved by Nginx.

However, in a development environment, you definitely have a benefit of UPWARD: It allows you to play with a custom domain and SSL-certificate (actually generated by buildpack) without running into cross-domain issues and CORS errors. There are different workarounds for CORS (my own Yireo module, Heroku corsanywhere app). But still, you could say UPWARD is useful in development.

My main point so far is: You don't need Node in a production environment. And you don't need UPWARD either. However, this is still not the full story. Because we need to add in Server Side Rendering into the picture.

What is Server Side Rendering?

When a browser downloads the HTML document from the server (no PHP or Node involved there), it receives an HTML skeleton with no content. Quickly, the JavaScript libraries of React are loaded and through React components, the entire page is rendered. This also involves various requests to the server (GraphQL, REST) to fetch content (products, categories, customer session, cart session, etcetera). Most importantly, all of this content is built using JavaScript. It requires JavaScript in the browser.

So this does not work when the browser does not have any JavaScript. Nowadays, I don't take people that browse the internet with Lynx seriously. However, there are plenty of other user agents out there (like SEO robots) that don't have JavaScript enabled. For them, it would be more useful to render the HTML already on the server (basically allowing JavaScript applications like React to build their entire output on the Magento side, just like the browser would on the client side): Server Side Rendering.

O my god, could you explain again why this is needed?

JavaScript-driven web applications work fine in regular browsers. However, once the webpage is rendered in social media engines like Facebook, LinkedIn and Twitter, static HTML is required. Also, while Google uses JavaScript-capable bots to render your pages, those bots don't run as frequent as the regular HTML-only bots, leading to slow discovery of new content. And Google is not the only search engine out there.

In short, for SEO purposes and definitely when money is involved (like with e-commerce sites), Server Side Rendering seems a must.

Prerendering or on-demand SSR

The simplest way of getting some kind of Server Side Rendered output on the server is to open up your webpage in the browser, copy its HTML source and paste that on a static page on the server. Perfect.

This could be automated with scripts that run on the server (or elsewhere in the cloud): Let them call upon headless browsers (that still include JavaScript!) to generate HTML-files. And next, place those HTML-files on the Magento+PWA server. You can run this yourself or use (commercial) services for this. Take note though that running a headless Chrome instance requires quite some resources and can be slow. This kind of mechanism is often referred to as prerendering.

Besides prerendering, there is also the option of on-demand SSR: As soon as the request is received by the server, it calls upon some SSR mechanism that generates the page.

Note that the resulting HTML document might show all of the content required, readable for non-JavaScript-supporting user agents. But still, in a JavaScript environment, you want to benefit from all PWA features. So the original JavaScript files are still in there, so that the static HTML is still replaced by the dynamic JavaScript application. This is referred to as hydration.

What do you need for SSR?

With prerendering, there are scenarios where you simply modify your Nginx configuration and connect it to the SSR mechanism. There are other prerendering scenarios where Node is needed, but you don't necessarily need a Node server for this. However, for the on-demand SSR, it is most common to have a server-based Node app that calls upon the client-side part of the code to prerender this. It involves things like Reacts renderToString().

In general, most developers that implement SSR implement this with Node. You need Node on the server, if you want SSR. And if you care about SEO, you do want SSR.

Crazy loop

With Server Side Rendering, the complexity of a simple PWA goes up. Instead of just using React or Vue to build a frontend quickly, suddenly you need to take into account a complexer server setup. And why? To accomplish something that was already out-of-the-box possible with PHP-driven applications. It sounds like a crazy loop.

However, don't forget the progressive part of PWA: Thanks to the fact that client-side rendering is still used as well, we can still use progressively features in the browser, like push notifications, offline pages, new browser APIs, etcetera.

SSR services & Node middlewares

With SSR being quite a complex topic, I hope to see more and more SSR prerendering services to be offered on the market: This way, the developer is able to focus on React or Vue development, while the service provider takes care of SSR.

Likewise, the option for a Node middleware layer is also there. But perhaps, agencies don't need to build these themselves, but can reuse Node middlewares of others. Kind of like, middleware-as-a-service (MaaS). Maasento.

Conclusion

Do realize that PWA is the future and that SSR is required to make SEO a success. And between all of those three-letter acronyms (TLA), the right approach is needed. And as of yet, most people use the Node approach, so perhaps you should as well. Is Node needed on the server when running Magento PWA Studio? If you are new to this topic, most likely yes.