Aimeos 2019.01 major release

 

The new beta version contains a lot of improvements and focuses on:

  • Even more performance
  • Developer experience
  • Code cleanup

Performance improvements

Aimeos is already known as ultra fast e-commerce solution for Laravel, Symfony, SlimPHP, TYPO3 and Flow/NeosCMS even for complex requirements. This release pushes the limits teared down by Aimeos #gigacommerce further with render times of 20ms and below if content caching is enabled. Without caching, response times are exceptional too compared to other shop systems and in the 2019.01 release, we reduced that time further.

First, we denormalized tables that use types, so the type code is now stored directly instead of the type ID. This saves several database queries per request. Additionally, it’s possible to retrieve related data for e.g. products filtered by type:

$manager->searchItems( $filter, ['text', 'price', 'product' => ['suggestion'] );

This fetches related products of type “suggestion” only instead of all related products. Especially for shops with many relations, this can be a huge performance improvement if components can’t be cached.

PHP 7.3 promises another huge performance improvement and we are testing that version every time. Unfortunately, there’s a bug in PHP 7.3 with prevents production usage yet. It seems that the PHP developers over-optimized opcode caching so PHP 7.3 produces wrong results: https://bugs.php.net/bug.php?id=77310

Simplifications for developers

One of the major goals for this Aimeos release was to simplify interfaces so the first steps for new developers are easier. As a result, creating managers, controllers and clients requires only:

$manager = \Aimeos\MShop::create( $context, 'product' );
$cntl = \Aimeos\Controller\Frontend::create( $context, 'catalog' );
$client = \Aimeos\Client\Html::create( $context, 'catalog/lists' );

Items with relations are fetched recursively now and a decorator limits the recursion depth to two levels. The allowed depth is configurable like everything else in Aimeos. This allows you to get all releated data you need at one without fetching and merging data from several calls to searchItems():

$products = $manager->searchItems( $filter, ['product', 'price', 'text] );

For bundle and selection products, the items in the result list contains the bundled and variant articles including prices, texts and related products.

Also, all newly created items have the status “enabled” by default and must be explicitly disabled if required. This saves many calls to “setStatus()” especially when implementing a new importer. The frontend controllers allow multiple category IDs for filtering so it’s possible to search for
products in multiple categories with one method call.

Code cleanups

Finally, a lot of old code has been removed due to the switch to document oriented managment of items. Especially in the index managers and the filter criteria implementation was some code left after the changes required to use ElasticSearch natively.

The 2019.x releases are the last ones that will support PHP 5 as 5.6 isn’t maintained any more since this year. You should use PHP 7 nevertheless to get the best performance.

For a full list of backward incompatible changes, please have a look at the Wiki article. BC breaking changes in 2019.01 are listed up to 2018-12-31:

https://aimeos.org/docs/Developers/Changelog#Version_2019.x

 

What is an e-commerce framework?

The term e-commerce framework is related to software frameworks for e-commerce applications. They offer an environment for building e-commerce applications quickly.

E-Commerce frameworks are flexible enough to adapt them to your specific requirements. As result, they are suitable for building virtually all kinds of online shops and e-commerce related (web) applications.

An e-commerce framework must

  • allow replacing all parts of the framework code
  • forbid changes in the framework code itself
  • contain bootstrap code to start the application
  • be extensible by user-written code

E-Commerce frameworks should

  • define the general program flow
  • consist of reusable components
  • be organized in functional domains

They provide an overall structure for e-commerce related applications.

Furthermore, they implement the general program flow e.g. how the checkout process works. Contrary to monolithic shop systems, existing program flow can not only be extended but completely changed according to your needs.

Evolution of e-commerce systems

Since the beginning of (internet) e-commerce around 1995, a lot has changed on the technology side. The first generation of e-commerce systems evolved from existing ERP and related systems. This was followed by the 2. generation of standalone shop systems between 2004 and 2008. E-commerce frameworks are the latest generation of e-commerce systems and started around 2012.

Hybris, the shop system owned by SAP is one of the representatives of the 1. generation. It’s strongly connected to the SAP ERP system and Hybris is mainly a shop front-end for SAP. Customer relationship (CRM) and content management (CMS) tools are available in the ERP system but very limited.

The Magento shop system represents the 2. generation of standalone e-commerce systems. They usually contain CRM and CMS and some other functionality but also only at a very basic level. They might be enough for the smallest shops but are unusable for shop owners who run for real profits.

Aimeos is one of the few real e-commerce frameworks that are currently available. These 3rd generation systems excel in their own domain: Present and sell products. For all other e-commerce related tasks, they connect to specialized systems and exchange data in both ways. Thus, shop owners can choose the best systems for their needs.

E-Commerce framework architecture

E-commerce frameworks must be based on a strong architectural model. Usually, they make heavy use of interfaces and design patterns like

  • Dependency Injection (make components independent of used object implementation)
  • Factories (create objects at a central place that instantiates the actual implementation)
  • Decorators (dynamically add functionality to existing objects)
  • Publish/Subscribe model (notify listening objects about changes instead of polling for updates)

A “design pattern” is re-usable solution that solves similar software design problems in an elegant way. They require programming language templates which enforce public class methods and their signatures called “interfaces”.

The basic requirement are independent, side-effect free components that form the building blocks. One or more components care about the functionality of a business “domain”. Such a domain can be the HTML front-end, a JSON REST API and the administration interface.

The vertical separation of code into business domains enables scaling out applications by deploying the application as a bunch of micro services.

Micro services are loosely coupled applications that offer their service over lightweight protocols like HTTP and JSON. They are easier to extend, maintain and especially deploy than monolithic applications.

More about Aimeos

Was ist ein E-Commerce Framework?

Der Term E-Commerce Framework bezieht sich auf Software-Frameworks für E-Commerce Applikationen. Sie ermöglichen es in relativ kurzer Zeit komplette E-Commerce Applikationen zu bauen.

E-Commerce Frameworks sind flexibel genug um sie an kundenspezifische Anforderungen anzupassen. Dadurch können sie als Basis für praktisch alle Arten von Onlineshops und E-Commerce bezogene (Web-)Applikationen dienen.

Ein E-Commerce Framework muss

  • es erlauben, jeden seiner Bestandteile zu ersetzen
  • Änderungen am Framework-Code selbst verbieten
  • Bootstrap-Code beinhalten um die Applikation zu starten
  • erweiterbar für kundenspezifischen Code sein

E-Commerce Frameworks sollen

  • den allgemeinen Programmablauf definieren
  • aus wiederverwendbaren Komponenten bestehen
  • in funktionalen Domänen unterteilt sein

Sie bieten eine komplette Infrastruktur für E-Commerce bezogene Applikationen.

Weiterhin implementieren sie den allgemeinen Programmfluss, z.B. wie der Checkout-Prozess funktioniert. Im Gegensatz zu monolithischen Shopsystemen kann der bestehende Programmfluss nicht nur erweitert werden, sondern auch komplett für die eigenen Bedürfnisse geändert werden.

Evolution von E-Commerce Systemen

Seit dem Beginn des E-Commerce im Internet um 1995 hat sich vieles auf Seiten der Technologie verändert. Die erste Generation von E-Commerce Systemen entwickelte sich aus existierenden Warenwirtschaftsprogrammen und ähnlichen Systemen. Daraufhin folgte die zweite Generation von eigenständigen Shopsystemen zwischen 2004 und 2008. E-Commerce Frameworks sind die neuste Generation von E-Commerce Systemen und begannen ab 2012 auf den Markt zu kommen.

Hybris, das Shopsystem von SAP ist einer der Vertreter der ersten Generation. Es ist eng mit dem SAP ERP System verzahnt und Hybris ist hauptsächlich eine Shopoberfläche für SAP. Customer Relationship (CRM) und Content Management (CMS) Werkzeuge sind im Umfeld von SAP verfügbar aber mit eingeschränkter Funktionalität im Gegensatz zu spezialisierten Systemen.

Das Magento Shopsystem repräsentiert die zweite Generation von eigenständigen E-Commerce Systemen. Sie beinhalten CRM und CMS Komponenten sowie ein paar weitere Funktionalitäten, aber ebenfalls nur mit einem beschränkten Funktionsumfang. Sie können für Kleinstunternehmen ausreichend sein, für Shopsbetreiber mit größeren Umsätzen aber meistens unbrauchbar.

Aimeos ist eines der wenigen echten E-Commerce Frameworks die im Moment verfügbar sind. Diese Systeme der dritten Generation glänzen in ihrer Kerndomäne: Der Präsentation und dem Verkauf der Produkte. Für alle weiteren E-Commerce bezogenen Aufgaben verbinden sie sich mit spezialisierten Systemen und tauschen Daten in beide Richtungen aus. Dadurch können Shopbetreiber das jeweils beste System für ihre Bedürfnisse wählen.

E-Commerce Framework Architektur

Gute E-Commerce Frameworks müssen einer stringenten Architektur folgen. Dafür verwenden sie ausgiebig Interfaces und Design Patterns wie

  • Dependency Injection (Komponenten sind unabhängig von der konkreten Objektimplementierung)
  • Factories (erzeugen zentral Objekte und instanzieren die tatsächliche Implementierung)
  • Decorators (fügen dynamisch zusätzliche Funktionalität zu existierenden Objekten hinzu)
  • Publish/Subscribe (benachrichtigen registrierte Objekte über Änderungen anstatt wiederholt auf Änderungen zu testen)

Ein “Design Pattern” ist eine wiederverwendbare Lösung, die ähnliche Softwaredesign-Probleme elegant löst. Sie benötigen Schablonen names “Interfaces” in den Programmiersprachen, die öffentliche Klassenmethoden und ihre Signaturen erzwingen können.

Die wichtigste Anforderung sind unabhängige Bausteine ohne Seiteneffekte, die zu Komponenten zusammen gefügt werden können. Ein oder mehrere Bausteine sind für die Funktionalität einer Fachdomäne zuständig. Eine Domäne kann eine HTML Oberfläche, eine JSON REST API oder eine Administrationsoberfläche sein.

Die vertikale Trennung von Code in Fachdomänen ermöglicht es Applikationen beliebig zu skalieren, indem sie als Microservices auf mehreren Serverinstanzen laufen können.

Microservices sind lose gekoppelte Applikationen, die ihre Dienste über leichtgewichtige Protokolle wie HTTP oder JSON anbieten. Sie sind leichter zu erweitern, zu warten und auszurollen als monolithische Applikationen.

Mehr über Aimeos