Meet the people

GraphCommerce is a new solution, created by the Dutch agency ReachDigital. The people of ReachDigital have been in the Magento community for ages: The former H&O company was renamed in 2018 (even though their GitHub space still reflects their old name). On the open-source front, they published numerous of their extensions, with little things like Advanced Template Hints, MSI add-ons and language packs.

One of my personal favorites is their QuickIntegrationTesting framework. I use it on a daily basis to speed up Integration Tests for Magento module development. With their framework (and various other tricks), I'm able to run a single test in less than 2 seconds.

Meet GraphCommerce

GraphCommerce is a new PWA solution, based on NextJS, so based on React. It ships with plenty of TypeScript definitions to add stronger typing. And it comes with Material UI - less my favorite (but that's more because I dislike CSS in general).

And obviously, the name is derived from GraphQL. But instead of using Apollo Server (like many other PWA providers have advocated), it is opting for GraphQL Mesh. Apollo really requires all backend services to be GraphQL-driven, so that non-GraphQL services (SOAP, XML-RPC, JSON) need to be integrated in a custom way. GraphQL Mesh makes this a lot easier by using resolvers that could easily be configured through .meshrc.yml.

To be fair, Igor Miniailo (chief architect at Adobe Commerce) also wrote about how they are working towards Mesh integration (see his LinkedIn post), so that this also might be part of the PWA Studio stack. But it is refreshing to see how GraphCommerce deals with this: For instance, they make use of an external CMS GraphCMS (which is now Hygraph), instead of struggling with PageBuilder.

And here is a demo: https://graphcommerce.vercel.app/ Which is nice.

Why not PWA Studio?

Still, the question could be asked what makes GraphCommerce a better fit than PWA Studio. Obviously, this is very opinionated. But as I see it, one of the big winning points of GraphCommerce is that it does not try to reinvent the wheel: It makes use of NextJS, which ships with features like routing, pages, layouts, plugins and SSR - swapping out the PWA Studio specific stuff for generic NextJS tech. (And let me comment upon extensibility below.)

If you know PWA Studio, you might agree that UPWARD has always been weirdish to work with. The NextJS SSR approach feels much more straightforward and stable - and it is backed by a much larger community. I've heard the argument before that PWA Studio is to be preferred, simply because it is backed by Adobe. But I would like to point out that the majority of Adobe has nothing to do with the open source project of PWA Studio. And the number of developers involved with NextJS is hugely higher than the number of developers (Adobe and community) involved with PWA Studio.

Getting started

To get started, read the docs. Really. At first, I glanced at the docs quickly, hacked around and then bumped into severe issues, which were actually documented. To name a few: Use Node 14. In my case, Node 16 failed because of dependencies being calculated in the wrong way. This feels a bit outdated, since Node 14 is in maintenance phase only, Node 16 is active but Node 18 is current. But perhaps this could be updated in the near future. It doens't make the entire GraphCommerce stack feel old at all (I guess).

The docs (which I'm not going to copy-and-paste from, you should read it yourself) tell you to get started by cloning the existing repository (or actually an example codebase). There is no easy installer (like with VueStorefront and PWA Studio) yet. After the cloning, an .env file makes configuring things easier. But still, manual modifications are needed.

Once all goes fine, yarn codegen generates things like GraphQL schemas locally (introspection). Next, yarn dev kickstarts a NextJS development server with local PWA. There you go.

My personal struggles

The docs still referred to GraphCMS, which is now Hygraph. Setting up a new project in Hygraph is easy, but this would mean you would start from scratch. The example codebase of GraphCommerce assumes existing schemas, queries and mutations. So make sure to clone the existing Hygraph project, instead of creating it from scratch.

After running yarn dev, I ran into various unforgiving errors: For instance, Unable to find field "pickupLocations" on type "Query". In the GraphCommerce Slack, I found mention of this: A new Magento module would add a new field to the GraphQL schema and this was also used in various parts of the PWA code. I didn't have that module, so needed to modify components and queries.

Likewise, an error Unable to find field "createBraintreeClientToken" on type "Mutation" popped up. This was properly documented though. Either the payment module (with its GraphQL part) needed to be added to the Magento instance, or the payment component in the checkout (pages/checkout/payment.tsx) needed to be modified. The same for Mollie. I hacked the code again and removed the deps (yarn remove @graphcommerce/magento-payment-braintree @graphcommerce/mollie-magento-payment).

Extensibility

Even though the end result was a working demo, it struck me (not negatively, just a struck) that there was no extensibility here. There was no easy way to add payment methods, except just adding the right code to the right component. GraphQL schemas were dynamically built, but the final queries and mutations would need modifying. On the Magento part, this would be the case. But on the CMS part, this would be true even more: Once you create your own Hygraph project with custom content-types (and what so), the React codebase would need to be modified quite a bit to facilitate this.

No extensibility sounds like a bad idea if you are a Magento developer (that is used to working with a monolith). But actually from the perspective of headless frontending based on React and Vue, this is actually quite common. Most JS developers will want to build up their own component tree from scratch anyway. They opt for freedom instead of having free stuff they don't want. If you know about the extensibility of Magento PWA Studio (like targetables), extensibility could become so flexible that is becomes terrifyingly complex.

Free as in free architecture, instead of freebies

Hence, GraphCommerce seems to have made a choice for making it easier for NextJS developers to build their own PWA with Magento connectivity, instead of making it easier for Magento developers to cross-over to NextJS. I personally see this is a solid choice. But it does mean that you need to you need to favor creating your own NextJS projects over customizing the code of someone else.

Still, there is plenty in the GraphCommerce suite that is likeable: Their choice of NextJS, numerous NPM packages that are made reusable, a solid example project, the usage of Mesh. As of yet, it is not for the faint of heart. But to fair, neither is PWA Studio.

Kudos to GraphCommerce for bringing a fresh new approach to the table.