Adobe Magento 2 Headless: Decoupled eCommerce App
Magento came a long way from its start as a good open-source eCommerce platform that powered 40% of the web stores. It is still alive as an Open source fork and well Known as Open Mage(https://github.com/OpenMage/magento-lts). A long 10 years later it became the Adobe enterprise's first commerce platform with overengineered bloated architecture with 1500+ open bugs in GitHub. Sales strategies become more important than software development.
Magento core architects create overcomplicated stuff and then explain it to other developers, who then are impressed because of the complexity and compliment the person who created this complex thing by calling them smart or whatever. We celebrate the wrong things.
All that Magento's official best practices are regular software development worst practices. That's why we can’t find any Magento store with performance and implementation.
Agencies that are full from that official scam designed their own solution that works much better than Magento 2 itself:
- Divante — Vue Storefront
- integer-net— Hyva
- Kirill Morozov — Magento 2 API using C++ (https://github.com/kirmorozov/cpp-m2-rest-api)
The only good best practice is not to follow Magento silly practices and create better software. Headless is completely about that, not using Magento partially (Frontend) or completely (like VueStorefront) and build better stuff.
REST API is part of the Magento core, developers can experiment and use it in a decoupled way, i.e. writing the front-end part by using JavaScript frameworks or libraries ReactJs or VueJS.
So, What Exactly Is A Decoupled Magento?
When it comes down to how Magento is designed, one thing is certain: it follows the Model-View-Controller (MVC) design pattern with an overcomplicated and outdated layout XML and KnockoutJs UI components with a lot of spaghetti PHP,pHTML,XML,Knockout,Jquery spaghetti code.
Modern Headess APP doesn’t need MVC it needs only data. Each controller is a separate microservice. Microservice can actually have the MVC pattern like using frameworks like Express JS.
It’s an all-in-one system that is equipped with a working admin interface; it manages database connection and has a bunch of useful APIs exposed that handle user authentication, products, cart, and more.
But thanks to the REST API and Magento less microservice, you can separate the Magento backend that handles data manipulation and database interaction, and use REST API Controller or API Gateway and Lambda to interact with a separate view layer using various API endpoints. In addition, you can place the JS App on a separate server.
ADVANTAGES OF USING THE DECOUPLED MAGENTO APPROACH
One thing why you may want to use this approach is to ensure a separation of concerns. The frontend and the backend are interacting via endpoints; each can be on its separate server which can be optimized specifically for each respective task, i.e. separately running a PHP app and running a Node.js app or Go app.
By separating your frontend from the backend, it’s easier to redesign it in the future, without constantly troubleshooting Magento core and UI. Also, front-end developers only need to care about what to do with the data the backend provides them. This lets them get creative and use modern libraries like ReactJS or VueJS to deliver highly dynamic web apps. For example, it’s easier to build a PWA when using JS libraries.
Another advantage is reflected in the website security. Exploiting the website through the backend becomes more difficult since it’s largely hidden from the public.
FIXING SLOW RESPONSE TIMES WHEN USING THE DEFAULT REST API or GRAPH QL
For anyone who has tried to build a Headless Magento site, this is not a new thing — Magento 2 Framework and REST API is extremely slow.
My team after a bit of investigating, realized the default REST API calls were actually really slow, especially when we “burdened” the site with additional plugins. So, we did a small test. We installed a couple of Magento plugins and encountered some interesting results. The postman app gave the load time of 1.67s for 65.3KB of response size. Just to retrieve a simple list of products. No taxonomy, no user data, no additional meta fields.
Why did this happen?
It turns out that accessing REST API on the default Magento will auto load the entire core to serve the endpoints, even though it’s not used. Also, the more Magento plugins you add, the worse things get. The default REST entry point is really big that does a lot more than necessary when building a simple web page. It handles routes registering, permission checks, configuration load.
Graph QL is more Broken than the rest of API it has more layers of obfuscation. Adobe and Magento don’t find a better solution except add Full Page Cache to this entry point. However, every good software engineer knows cache doesn’t improve care performance it just makes the response more static. It is definitely better than without cache but it doesn't resolve real issues.
Improving Magento Performance With The Magento less Microservice Approach
When you are working with simple presentation sites, you don’t need all the stupid functionality Magento REST API or especially Graph QL offers you.
For that reason, I'm using Magento Microservices Framework that can help you out when serving simple JSON data without loading outdated, built using Zend Framework 1 Magento 2 core.
There is an example of the implementation :
https://yegorshytikov.medium.com/magento-microservices-and-node-js-639afbc7c8c4
Magento usage statistic sows how current Magento architecture killing the Magento ecosystem and M2 slowly going to hell :
