Adobe Commerce Magento-less micro-services architecture

Microservice architecture is a design pattern that separates an application into independently deployable services. Each independent service communicates with the others through lightweight APIs or a Data layer. This service can use different programming languages different than PHP and are free from the Magento 2 best practices. You are building Magento micro services following best software development practices and KISS principles without overcomplicating things like the Magento team does.

Magento 2 microservices, such as orders, product catalog, and checkout, provide an API through service. Font-end interacts with these microservice through GraphQL or REST or direct database communication and server-side rendering with HTML response.

Micro Services have different entry points for catalog and admin scenarios. We are applying different rules and restrictions for such points depending on where these objects appear. Initially, we do not have Authorization ACL resources specified for the front-end services. So, there are no particular reasons to keep admin and frontend microservices together. Instead, make sense to separate Magento e-commerce microservices per purpose and extract specific modules that will serve storefront applications.

Microservices can manipulate with raw data sources such as PostgreSQL, Redis, MongoDB, ElasticSearch, etc., using 3-d party (not Magento 2) libraries (ORM, routers) and frameworks such as NodeJS(ExpressJS), Laravel, Python. Microservices work mostly with denormalized Magento data to return data most efficiently. Magento legacy logic can work. For example, the Price indexer can still run by corn and pre-populate the price indexer after the microservice selects it directly from the database and ships to the frontend as HTML or JSON. As microservice developers and owners, we create our own “indexer” by creating cron microservices to populate our storage such as PostgreSQL or MongoDB, RedisJSON. RedisJSON itself should make any Redis user giddy with JSON joy. This feature provides a new data type that is tailored for fast and efficient manipulation of JSON documents. RedisJSON’s values are stored in keys that can be accessed with a specialized subset of commands like any Redis data type API that the module exposes, which is ned to be intuitive to users coming to Redis from the JSON world and vice versa.

Microservice can operate with eventually consistent data (indexer). At the moment, Magento follows this principle. Storefront queries use pre-baked data. So exists some delay between the moment when data was submitted to the system and when data becomes available for microservice. You custom indexers you can write using any language different from the frontend API microservice or glued is Database or Redis.

Current Magento 2 / Adobe Commerce OOP architecture is terrible and produces many N+1 SQL queries. Microservice should utilize 1 or a little bit more requests to data storage per request. 95% response time of the microservice shouldn't be grate than 100ms. However average response time should be around 30ms. Microservice can have cache, ut it should work without cache fast as well.

Microservices do not depend on each other. The module's purpose is strictly restricted by the scenario it introduces. They are no particular reason to do this because the presentation layer will perform all aggregation.

Because we are going to manage Magento microservices as a set of small granular modules which do not rely on each other and can be replaced by other microservice.

Magento Micro service Libraries ->

Suppose you want to use Magento exclusively as a backend(admin) system without reusing outdated Zend Framework 1 based M2 core framework. Exploit Laravel’s Eloquent ORM to get data:

NodeJS implementation of the Magento 2 ORM without using legacy PHP

This repo uses Sequelize to connect to the MAgento 2 database directly without invoking the broken MAgento 2 PHP framework, so we won’t have to write any MYSQL queries.

Sequelize is a pretty great ORM with Magento.

Magento Rest API implementation using Pistache C++ Framework Communication with MySql is done though XDevAPI

Admin login (index.php/rest/V1/integration/admin/token) works using libsodium, with the same encryption as within Magento Core. Primitive ACL validation was added for some basic GET methods implemented.

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