Magento 2 Graph QL architecture issues

Think of who created it, Facebook, they created this piece of tech to suit their own needs, which I can argue is not what I would consider a general need, but rather driven by their business requirements. eCommerce is a basic trivial web application and many think it is not the best fit For Magento.

Graph QL originally designed to replace backend with universal HTTP based query language.

Magento application is connected to a PHP server. That server could be sending the data using different protocols (HTTP, FTP, HTTPS) and designs (SOAP, REST, something similar to REST), and the Magento framework has to deal with that so for that reason we would always like to have a service layer inside our architecture.

GraphQL is a runtime to access your existing data. basically, it is completely replaced Magento. It can access your data directly to the database. However, Magento has a broken database model and ORM and in the case of Magento, Graph QL sends queries to the legacy app and doesn’t remove legacy just mask it.

GraphQL is able to communicate with lots of different kind of entities, they could be a SQL or NoSQL databases, REST APIs, 3rd-party APIs, legacy systems (Magento 2), or even other GraphQL APIs.

Issues with graph QL in Magento :

A GraphQL API is supposed to return an HTTP 200 response even for failed requests because the graph resolvers model means _part_ of your query may fail while the rest succeeds. This is logical, albeit unnatural, and not well-suited to existing HTTP tools.

N + 1 to many SQL queries issue

What are n+1 requests?

n+1 requests are the most obvious issue when using a GraphQL backend. It’s easy to illustrate with a simple relation. You have an Order type that has a relation to a Product type.

type Order {
id: ID
address: Product
}
type Product {
id: ID
Name: String
SKU: String
}

Now, let’s assume you have a simple query returning a list of Orders, a GRAPH QL client might do this query:

query GetOrderList {
orderList {
id
product {
id
name
SKU
}
}
}

That’s it for the context. Now to understand the issue we have to follow the GraphQL flow of resolution:

First step: somehow, the orderList query resolver will return a list of Orders by making, most likely, one single query to the store

Second step: for every n order of this list, GraphQL will need to resolve the product attribute. This means it will go through the product resolve function n-times, most likely triggering n requests to your datastore.

This is what the “n+1 requests” expression comes from.

In 97% of cases, this is a very suboptimal way to fetch several elements.

PHP is I/O Blocking you can’t resolve hearts in a parallel

Graph resolvers designed to be called in parallel by default, data will load faster. However, with Magento, this cool feature doesn’t work. The native Language for Graph QL is JS non I/O blocking not PHP. JS has big advantages in asynchronies resolver execution. With PHP you will have the same slow performance.

Optimizing resolvers performance can be complex. You need doe resolvers optimization, like joins, batch systems. GraphQL will not improve your Magento performance — it is just a query language. Graph QL can harm your performance if the user-defined query is bad! The nature of GraphQL is that you can query combining whatever fields you want but, this flexibility is not for free. There are some concerns that are good to know like Performance and N+1 Queries.

It’s easier to use a web cache with REST than with GraphQL

I want to emphasize the web part, caching at the network level, because you can certainly implement a cache at the database level or at the client level with the in-memory cache implementation of Apollo Client.

But a cache implemented at the HTTP level (for example with a reverse proxy) that stores the content of a request can reduce the amount of traffic to a server or keep frequently accessed information in a location close to the client (like a content delivery network).

Since a REST API provides many endpoints, you can easily configure a web cache to match certain URL patterns, HTTP methods, or specific resources.

In GraphQL, there’s only one endpoint (most of the time an HTTP POST endpoint) where all the queries are sent. Since each query can be different, it is harder to use this type of caching.

Graph QL is a new complexity

GraphQL and REST are both very different things, GraphQL is a language and a technology, REST is an architecture pattern.

Although GraphQL is very useful to solve complex data exchange, it is “over-engineered” to use it for simple or standard use cases.

PWA has no need to use heavy GraphQL API — after all, REST is just HTTP with convention, so, simple to implement and use.

GraphQL data is to open

Graph QL doesn’t have Information hiding — “ability to prevent certain aspects of a software component from being accessible to its clients.” Furthermore, “a common use of information hiding is to hide the layout for data so that if it is changed, the change is restricted”.

Specific Response Structure

In GraphQL the response matches the shape of the query, so if you need to respond in a very specific structure, you’ll have to add a transformation layer to reshape the response.

Simple APIs

In case you have a service that exposes a really simple API, GraphQL will only add extra complexity, so a simple REST API can be better.

And finally, I think the use of GraphQL for super simple APIs is a waste of time, just adding more complexity and dependencies to your project.

There is no silver bullet… GraphQL is a really good tool, but have some drawbacks just like any other. Being aware of these disadvantages will help you prevent problems.

Millions of new and old services (Youtube, Uber )using regularResta API without any Graph QL, and works well. Why everyone decided that GrapQL will fix all Magento problems? Especially performance, if GraphQL doesn’t affect broken architecture just adding new bugs and abstraction.

Magento/APP Cloud Architect. Melting metal server infrastructure into cloud solutions.