Update from December 08, 2020: Practical experience from several projects has shown that in our opinion the PWA approach is not suitable for all Magento projects. With Hyvä we have therefore developed a new approach for a high-performance and above all simpler frontend. More information about Hyvä Themes can be found here:

This is part 3 of a series of blog posts on the topic of PWA. If you want to find out more about PWA for Magento in general, please read the first post of this series: PWA: A new Frontend for Magento 2 and why it is necessary. If you want to know more about Deity, the company, and how integer_net is involved, read PWA and Magento: About DEITY

Today I am going to give a broad technical overview of the Deity software.

The heart of Deity is a node.js application with a shared code base for client and server. This will look very familiar to JavaScript developers and as a standard node.js application benefits from the vast node/npm ecosystem. The core itself is an npm module which you pull in as adependency into your application. Currently, some features are being extracted, so in the end it will be a set of multiple smaller modules so that the various integrations (Magento, WordPress etc.) will be optional.

Why node.js? The node.js event loop architecture makes it a fast backend that is well prepared to handle parallel requests. There is no startup time overhead like in traditional PHP, so the response time is faster than Magento can ever be for anything dynamic, i.e. without Varnish. Also, having a shared codebase in the same language for the client-facing frontend and the server-frontend results in more seamless frontend development, decoupled from the backend.

As libraries for a component based user interface, React has been chosen, together with Redux for state management.

Architecture Diagram

The Deity Stack

The decoupled frontend can be developed almost without any Magento specific knowledge.

Core Features

With Deity you get a single page app (SPA), but thanks to dynamic URL changes and additional server side rendering the navigation in the browser feels natural as well, and also is SEO friendly. As a side note, the Google search crawler is able to execute JavaScript, so server side rendering is not that important from a SEO perspective anymore.

Requests to the node.js backend are routed to the appropriate backend API. Deity comes with connectors to Magento 2, to WordPress for CMS and blog functionality and to Algolia for catalog search. API responses are cached to reduce the bottleneck of the slow Magento REST API.

Deity has a fully functional checkout with PayPal and credit card payment via Adyen, an internationally operating Dutch payment service provider. Credit card payment is integrated without using an iframe. You confirm your payment on the third party site, like it is known from PayPal and other PSPs.


Deity was built with service oriented architecture (SOA) in mind. There are multiple backend services connected to each other and the frontend via API. Currently, there is Magento for catalog and checkout, WordPress for Blog and content management and Algolia for search. A WordPress plugin that connects WordPress to the Magento API allows adding product widgets to posts.

But there is more to come. Deity is partnering with Dare.IT to integrate a full suite of SOA solutions (named DEITY Enterprise) for customer, order and stock management and more, where Magento is not sufficient on enterprise level.

Deity Enterprise Integrations

Backend Integration: Magento API

To work effectively with Magento, the REST API had to be extended a lot. At time of writing, there are 24 new and 6 overridden API end points. Most are related to customer account management, checkout and payment. Whenever possible the Magento module adds missing data via extension attributes instead of overriding the API.

Together with Óscar Recio, Magento Github maintainer and top 3 contributor of 2017, we are working on making the module comply to the standards with the end goal to migrate as much as possible to the Magento core via pull requests. Until then, the module will be released separately so that it can be used as foundation for headless Magento even without Deity.

For the Adyen payment method, there is a separate Magento module which extends the API of the official Adyen_Magento extension.

Backend Integration: WordPress API

The WordPress API is already quite useful out of the box, but some additions have been made, for example to support multiple languages (via WPML plugin), custom fields (via ACF plugin), custom menus, popular posts, and to retrieve posts based on URL.

There is a Deity composer project template for WordPress that contains all necessary plugins.

Backend Integration: Search

Search requests can be routed directly to Algolia. Algolia is a third party service which already has a Magento extension. It can be used to index products from Magento. We are planning to offer Solr as drop in replacement, for merchants that want to host the search database on their own or need more customization than Algolia offers. The refactored architecture of our IntegerNet_Solr extension will make it easy to adapt to a new frontend.

Project setup and development

Setting up a new Deity project is a straightforward process. Deity comes with a template for the interactive scaffolding tool Yeoman. After installing Yeoman and the template, you type

and follow the instructions on the screen. When the template has updated, you can also run this generation command again in an active project and interactively choose which updates to apply.

This gives you a head start to develop the project based on the default theme. Alternatively you can as well build a frontend from scratch using the provided components of the Deity core module.

Lots of dependencies are already needed for yeoman and the deity template. Usually you will have them already installed on your system (e.g. Python), except if you run a minimal Linux. I’ve created a docker image where everything is pre-installed. With that image you can generate projects without additional dependencies. It is based on the official node.js container and thus can also be used to run Deity without further ado. When Deity is published, I will also publish the image, it might also become the official one.

To develop the frontend you don’t need to have Magento (or WordPress) installed locally, because only the API is used and the tooling is independent from Magento. A remote development instance is sufficient.

The hot reload feature for the React frontend as well as the node.js backend gives you instant feedback in the browser. This should not be worth mentioning nowadays, but if you had to work with the standard Magento frontend, you will appreciate it!

Comparing DEITY with the PWA Competition

Deity started as agency internal project at Hatimeria and has already been reused for a number of eCommerce sites in 2017. In the current landscape of Magento PWA frontends, only FrontCommerce has that level of maturity. Incidentally, FrontCommerce has not only a similar history, but also quite a similar architecture (and a cute video about it). But they pursue a different business strategy, FrontCommerce will stay closed source with licensing fees, while Deity is tending to a model like Magento with an open source core and additional enterprise features.

With this background it is clear that Deity started as a minimum viable product with business critical features first, e.g. online payment. On the other hand, due the internal nature of the original project, there is some work to be done to make it ready for open source. It started with only as much generalization as needed, features that were not needed by clients were not implemented and big changes could be made without worrying about backwards compatibility.

Right now, getting ready for open source is the top priority of the Deity development team. That’s not meant in terms of new features, but things like API stability, modularity, extensibility and, last but not least, a security audit.

Architectural changes are necessary to have shop and blog modules as separate packages and to make the frontend API ready for a switch to GraphQL. Deity does not want to make the same mistake as Magento did with their 2.0 release and ship a half-baked product, then being afraid to change too much but still regularly break backwards compatibility. Early adopters should not be punished!

Of course we are also watching closely what Magento is doing with their own PWA Studio and how the Vue Storefront project by Divante evolves, which both seem to have a good amount of manpower behind them. From our perspective, they are not as far yet though. They still need to solve business critical problems like payment, while they are ahead in other areas like the offline mode. You can see that it has been approached from a different direction than Deity and FrontCommerce. Vue Storefront was built as open source from the beginning, to my knowledge without being accompanied by a client project. But by now, agencies are working on several Vue Storefront implementations and recently, the first one has been announced to be live, so it definitely has some momentum.

Why Deity chose React for the UI and not Vue would make up for another blog post. It’s more than just a matter of taste though: Vue is a complete frontend framework that makes it very easy to quickly build things as long as you stay in the boundaries of the framework, but gets in the way if not. React on the other hand is a library, not a framework. The entry barrier might be higher, but then you can integrate with other components as you like. It gives you more freedom to build whatever you want. Not coincidentally, Magento chose React for their PWA Studio, and Vue is popular amongst Laravel developers.

Magento PWA Studio is yet another story. The team around James Zetlen has constraints from Magento which make it a hard job for them. Basically, they have to please everyone at once, provide the most generalized and extensible solution as possible, at the same time develop a GraphQL API in PHP and stay in line with the Magento backend architects. All this leads to a high risk of overengineering and inventing their own Magento way of doing things, as we have seen in the past. What we already can see in the demos is that the tools are tightly coupling backend and frontend.

And since they don’t eat their own dogfood, i.e. build a real shop with their product, they rely heavily on feedback from the community. It is good to see that they actively seek this feedback via community engineering hangouts and other channels, and also started to show work in progress in the magento-research Github account.

We wish Magento best of luck with their PWA, and actually want them to succeed because it will benefit the ecosystem as a whole. But from a technical perspective, we like the decoupled approach of Deity more, so that’s where we put our money.

Fabian Schmengler

Author: Fabian Schmengler

Fabian Schmengler is Magento developer and trainer at integer_net. His focus lies in backend development, conceptual design and test automation.

Fabian was repeatedly selected as a Magento Master in 2017 and 2018 based on his engagements, active participation on StackExchange and contributions to the Magento 2 core.

More Information · Twitter · GitHub