The 2024.07 release completes the GraphQL API and adds some nice features to Aimeos. In addition, we’ve invested a lot of time to improve the documentation of the GraphQL and JSON APIs:

• GraphQL file uploads and new index query
• Extended GraphQL and JSON:API documentation
• Custom address types
• Full time support in subscriptions
• Multiple mailer support in Laravel

GraphQL API improvements

The GraphQL admin API will replace the existing JSON admin API completely beginning in 2025. The JS code of the Aimeos admin backend is rewritten step by step to use the GraphQL API only and thus, the GraphQL admin API has been further improved and is now almost feature complete.

The latest additions contain a new GraphQL index query that allows aggregating products matched by filters for counting or of aggregation. Also, The API supports uploading media files now – a feature, that’s not available in the the old JsonAdm API.

Until 2025, the remaining code that uses the JsonAdm API will be rewritten and the JsonAdm API will be finally removed.

API documentation

We’ve put a lot of effort in improving the API documentation for the GraphQL and JSON REST API.

Especially, the examples have been improved and they include vanilla Javascript code for the JSON API and JQAdm code the GraphQL admin API now. This enables developers of any skill level to get code for working requests quickly. Furthermore, existing examples have been improved to show how related items can be fetched too and how they are returned.

All new queries and mutations available in 2024.07 has been documented too in the GraphQL admin API and JSON REST API documentation.

Custom addess types

Up to now, it was possible to add addresses to customers and suppliers but they had a fixed meaning. For customers, the addresses are treated as delivery addresses while for suppliers, the addresses are locations for stores or with a similar meaning.

Now, the customer and supplier address tables contains a new “type” column that can contain any string to distinguish the different addresses stored there. This is especially useful in heavily customized setups which includes non-standard use cases, e.g. for complex B2B applications and marketplaces.

Time support in subscriptions

The Aimeos backend supported entering hours for subscriptions already in the past but the rest of the code wasn’t fully prepared to copy with subscriptions that should be only available for one or more hours.

Now, this feature is completely available in the whole code base including renewal of subscriptions after one hour if configured in the product subscription settings.

Multiple mailer support

In case you need to use different mail servers for sending e-mails depending on their purpose, Aimeos does support them now – at least if you are using Laravel. The mail() method of the Aimeos context object accepts the name of the mailer configuration now and returns the mailer object which uses the corresponding configuration. Existing code isn’t affected because the new parameter is optional and the default mailer is returned as before if no parameter is passed.

The first stable release of the Aimeos ecommerce framwork for Laravel and TYPO3 in 2024 offers a whole bunch of updates compared to previous versions and is prepared for the upcoming accessibility requirements in the EU. The most important features and changes are:

• Full Laravel 11 support
• WCAG AAA compatible template
• Top-level URLs for products/categories/pages
• Product CSV upload in backend and imports per site
• VueJS 3 in admin backend with locally bundled JS libs
• Improved GraphQL admin API
• Simplifications for developers

Full Laravel 11 support

The Aimeos Laravel package has support for Laravel 11 since its release a month ago. The number of breaking changes in Laravel 11 had been low so adapting the package was possible immediately.

Now, with the Aimeos 2024.04 release, the Aimeos shop distribution as well as the Aimeos headless distribution are based on Laravel 11 too. The most important change in Laravel 11 is the simplified ./app/ directory but the old structure is still supported. Only the AuthServiceProvider class isn’t used any more.

WCAG AAA compatible template

Starting in 2025, almost all companies in the EU need to have accessible web sites which can be used by handicapped persons too. The W3C Web Content Accessibility Guidelines provides useful help to comply to the required accessibility standards.

The default Aimeos theme as well as the Berlin theme for marketplaces is now prepared for WCAG 2.2 AAA. Most of the required changes related to controls, buttons and other active elements which needs to be big enough for easy usage.

Top-level URLs for categories/products/pages

The Aimeos Laravel package and the Aimeos shop distribution based on Laravel support now URL segments without sub-paths. Than means, you can have URLs like /sneakers, /nice-blue-top-sneaker and /contact as URLs for categories, products and CMS content pages.

All those top-level URLs are handled by the ResolveController, which checks if a category, product or CMS page with that URL segment exists. This feature isn’t enabled by default because it requires additional database queries to check what type of entity is assigned to that URL segment. The README of the Aimeos shop distribution contains a section how to enable the multi-routing feature.

Product CSV upload in backend and imports per site

One of the major changes in Aimeos 2024.x compared to previous versions is that CSV and XML files can now be imported per site in multi-site environments. Therefore, the files must be stored in sub-directories of the product, catalog, supplier, etc. directories named after the code of the site to import the files for within the fs-import file system.

That change allowed to implement uploading CSV files in the product list panel. Then, these files are stored in the appropriate directory of the fs-import file system and are processed by the product CSV job controller that needs to be executed regularly by a cron job because of time and memory constraints in HTTP requests.

VueJS 3 in admin backend with locally bundled JS libs

The Aimeos admin backend has been rewritten and uses VueJS 3.x for the dynamic features now. You will only notice the upgrade of the VueJS library if you have overwritten parts of the admin backend with custom templates. The code for initializing the VueJS apps must be different now as well as inline templates are not supported any more.

Instead of using the JS files from a content delivery network, they are now bundled by NPM and included from the local file system. This reduces the dependency from external CDNs, supports environment without internet connections and the bundled files are also smaller which improves the loading time.

Improved GraphQL admin API

The Aimeos GraphQL API is now almost feature complete. It can handle the necessary requests to fetch and manage all resources including the aggregations required for the dashboard. Compared to previous versions, the API supports getting the total number of items too. Only file uploads for the media resources are missing and will be added in the next version.

Beginning of 2025, the existing JSON admin API will be deprecated and removed in later versions so you should use the GraphQL API in the backend from now on. The JSON API for the frontend won’t be affected in any way and is the only supported option for fetching data for building your own frontend.

Simplifications for developers

We always work hard to make things as simple as possible for developers using Aimeos for their own projects. Creating new managers required to write a lot of code in the past but now, it has become very simple. The article about implementing new managers describes the few steps with examples that are required to create the necessary migration and the manager class which defines the properties.

In the HTML frontend, the address sections in the checkout process and the account profile page have been unified and use a common address partial now. Thus, they can be configured using the same settings now but that required renaming the existing configuration options.

To simplify the structure, the controller/common and controller/jobs code in the ai-controller-jobs extension has been merged and the controller/common code from the aimeos-core package has been moved to the media and order managers where they belong to.

The 2023.10 version of the Aimeos e-commerce framework for Laravel and TYPO3 is available now! Especially developers will love the 2023 version because it contains a lot of simplifications and fully supports scaleable cloud setups like Kubernetes natively. The most important updates in 2023 are:

• Laravel 10 distributions
• TYPO3 12 support
• Kubernetes/Serverless support
• Create managers easily
• Merged order and order base
• Stored basket panel
• DB-based translations for type names
• VueJS and GraphQL in backend

Laravel 10 distributions

Since the Laravel 10 release in February 2023, Aimeos fully supports the latest Laravel version and since 2023.04, the Aimeos headless and full stack distribution are based on Laravel 10. You can bootstrap your own Aimeos application in less than five minutes using those distributions and get a fully working Laravel 10 application. This also includes pre-configured authentication setup for both, the full stack and the headless distribution.

TYPO3 12 support

Also, Aimeos 2023.x fully supports TYPO3 12.4 since it’s release in April. Many changes has happened in v12 compared to v11, especially a lot of deprecated code has been removed. This made it very hard to make Aimeos 2023.x available for TYPO3 v11 too so we’ve decided to support v12 only in that release. Therefore, if you need a feature from Aimeos 2023.x or want to upgrade after two years of free support, you must upgrade to the latest TYPO3 v12 too.

Kubernetes/Serverless support

We are proud to announce that Aimeos 2023+ is the first cloud-native e-commerce solution for Laravel. Everything including file imports can be distributed across any cloud environment like Kubernetes, AWS, Google Cloud, Azure or so called serverless environments now. Aimeos for Laravel is cloud-ready since the beginning and images/CSS/JS files can be stored in S3 or similar cloud storage services but files were read only from a local file system. This this year, you can store files for importing products, categories, users, etc. from any remote server regardless if they are in CSV or XML format.

We also moved our complete server infrastructure from traditional hosting to a private Kubernetes cloud beginning this year including the web sites, demo setups and private package repository.

Create managers easily

Extending existing managers is extremely simply but writing new managers for own data domains or extending existing data domains required a lot of boilerplate code in the past. Since 2023.10, creating new managers is as easy as extending managers now.

First of all, create a setup task for the database migration as before:

namespace Aimeos\Upscheme\Task;

class Test extends Base
{
    public function up()
    {
        $this->info( 'Creating test schema', 'v' );

        $this->db( 'db-test' )->table( $name, function( $table ) {
            $table->engine = 'InnoDB';

             $table->id()->primary( 'pk_mstes_id' );
             $table->string( 'siteid' );
             $table->string( 'label' )->default( '' );
             $table->int( 'position' )->default( 0 );
             $table->smallint( 'status' )->default( 1 );
             $table->meta();
         } );
    }
}

Then, create the manager for the new domain named “test”:

namespace Aimeos\MShop\Test\Manager;

class Standard
    extends \Aimeos\MShop\Common\Manager\Base
    implements \Aimeos\MShop\Common\Manager\Iface
{
    public function getSaveAttributes() : array
    {
        return $this->createAttributes( [
            'label' => [
            ],
            'status' => [
                'type' => 'int',
            ],
            'position' => [
                'type' => 'int',
                'label' => 'Position for sorting'
            ],
        ] );
    }
}

That’s all! You can work with your new manager like with any other manager from the Aimeos core:

$manager = \Aimeos\MShop::create( $this->context(), 'test' )

$item = $manager->create()
    ->set( 'label', 'test label' )
    ->set( 'position', 2 )
    ->set( 'status', 1 );

$item = $manager->save( $item );

$label = $item->label;
// or using get() with default value
$label = $item->get( 'label', 'default value' );

For more information, there’s an article about creating new managers in the Aimeos documentation.

Merged order and order base

The biggest architectural change since the beginning is simplifying the order data domain by merging the order and order base tables/managers/items. The initial idea behind was that we can have several invoice/refund entries for each stored order base item (=basket) but that turned out to not work well over the years and complicated handling orders a lot. Thus, the data is all stored in the order record now.

That leads to some consequences, especially for the JSON:API as this change isn’t backward compatible! An application using the JSON:API doesn’t need to use the order endpoint any more to create an order item because the basket endpoint did that already. Furthermore, the property names in the basket changed and “.base” has to be removed.

The JSON:API has been backward compatible for six years (2017-2022) and we want to keep v2 stable for the next 5-10 years now.

Stored basket panel

Customer baskets are stored in the database during some time and now, the admin backend contains a new “Sales > Baskets” Panel in the admin backend. Administrators and editors can check saved and abandoned baskets of the customers and it’s also possible to send emails to 3rd party applications for reminding customers about their abandoned carts.

DB-based translations for type names

Before, translations for attribute types were only possible by translating them statically the Gettext translation files or in the Aimeos configuration. Thus, only developers were able to update these translations and it was difficult to update translations if they have been delivered by ERP systems.

Now, type translations are saved in the database along with the types and can be edited in the admin backend and updated easily by ERP systems. This is available for all types, not only attribute types.

VueJS and GraphQL in backend

Several panels have been rewritten in the admin backend to use VueJS components now. This lead to better code quality and is another step forward to remove all jQuery-related code in the next versions. Also, VueJS components for which no VueJS 3 version is available has been replaced by better supported ones, namely the combo box select components which have been replaced by Vue Multiselect now. Finally, this will make the upgrade to VueJS 3 possible in the next versions.

Furthermore, requests to the JSON admin API has been replaced by requests to the new GraphQL API where possible. We will continue to extend the GraphQL API and replace existing JSON admin API requests until we completely phased out the JSON admin API. In 2024.x, the JSON admin API will be also marked as deprecated. The frontend JSON:API will never be replaced and will be the only way for frontends to interact with Aimeos servers as GraphQL is not suited well for read-heavy applications like e-commerce apps.

Since the availability of ChatGPT, a large language machine learning model from OpenAI, artificial intelligence seems to be on the rise. Now, editors writing texts might be seen as a dying species because tools like ChatGPT can do the same in seconds and in almost the same quality. This is similar to how DeepL, a translation tool based on machine learning, changed the translation industry before.

Especially in eCommerce, search engines like Google require a lot of relevant text before pages show up at the top of search results. This can now be automated in Aimeos, the first eCommerce framework with direct integration of ChatGPT and DeepL. This allows editors to generate any text in seconds and have it translated into 29 languages.

Generate and translate any content

Not only texts based on existing product specifications are possible, but also helpful information for customers. Depending on the prompt entered, ChatGPT also generates, for example, styling tips for fashion or health information for allergy sufferers – everything about which there are already publications on the Internet that have been incorporated into the training of the AI model.

Although ChatGPT can generate texts in different languages, the quality is better the more texts are available in the respective language on the topic. Since DeepL can translate good quality texts into less common (European) languages, this will greatly accelerate the professionalization of online stores in these language regions.

Test yourself

You can try Aimeos and the capabilities of ChatGPT and DeepL yourself in the Aimeos admin demo:

https://admin.demo.aimeos.org/

Aimeos is the ultra-fast, cloud-native, API-first PHP eCommerce framework for building custom online shops, marketplaces and complex B2B applications. It’s available as Laravel package, Symfony bundle and TYPO3 extension.

The Aimeos 2022.10 version with long term support is now available for Laravel and TYPO3. It contains a lot of improvements for customers, editors, developers and marketplace owners. The most important improvements included in this release are:

• GraphQL admin API
• Headless Laravel distribution
• Direct editing of marketplace items
• Dynamic supplier filter
• Customers can save baskets
• Invoice numbers per site
• Optimized performance
• SEO and 404 improvements

GraphQL admin API

The biggest improvement in the 2022.10 LTS realease is the GraphQL API for administration, which enables developers to manage products and other data stored in Aimeos much easier compared to the JSON REST Admin API. Especially updating several related resources can be done in one API call now instead of requiring ten or more calls. The GraphQL API is also much more aligned to document based storage like ElasticSearch.

A GraphQL mutation to store a new product and return its ID looks like:

mutation {
  saveProduct(input: {
    code: "test-graphql",
    lists: {
      media: [{
        type: "test"
        item: {
          type: "download",
          url: "https://local/test.jpg",
          preview: "https://local/test-small.jpg"
          property: [{
            type: "copyright",
            value: "Aimeos"
          }]
        }
      }],
      text: [{
        type: "name",
        item: {
          type: "name",
          languageid: "de",
          content: "Some text"
        }
      }]
    },
    property: [{
      type: "prodcode",
      value: "abcd-1234"
    }]
  }) {
    id
  }
}

Headless Laravel distribution

The Aimeos headless distribution based on Laravel 9 is now stable and available with long term support too. It’s tailored for developers who want to build the complete frontend in Javascript using ReactJS, VueJS or any other Javascript framework. For authentication, JSON Web Tokens are used in the headless distribution and the world-class Aimeos JSON REST API offers access to the complete frontend functionality of Aimeos.

Get the Aimeos headless distribution

Edit marketplace items directly

In the past, editors have to switch to the site where the texts, images, attributes or other related items had been created before they could update or delete those items. Now, editors can modify or delete every item created in a sub-site of the current one directly, which is extremely handy in marketplace setups to fix items of vendors quickly!

For all those aggregated items (and also for inherited ones) where no space for additional information is available, the Aimeos backend displays the meta data like site, editor and creation/modification time when hovering over the item now. Therefore, you can see immediately from which site the item is coming from as well as who created/modified it and when.

Dynamic supplier filter

For those who have hundreds, thousands or more suppliers/manufacturers/brands in their Aimeos installation, the new supplier filter offers searching for those items dynamically. Thus, it’s not necessary to preload a limited set of items.

The filter enable customers to search for any supplier based on their name and it also finds sub-strings in supplier names. The most often used suppliers are still listed first when opening the filter and found items are added at the top.

Customers can save baskets

Customers can save their baskets now, which is especially useful for B2B clients who have selected the products they need for their customers and store the baskets until they get the final OK. Each basket can have a name describing the content.

Then, the stored baskets are listed in the profile section of the account just like for the order history. Customers can select one of the stored baskets and put all products inside into the current basket with a single click and continuing to the checkout.

Invoice numbers per site

Especially for marketplaces and SaaS setups, separate sequential invoice numbers for each vendor are important for accounting reasons. In 2022.10, Aimeos adds an invoice ID column to the locale site table and creates a new, unique invoice ID for each order after the payment was successful.

The ID from the order table is still used to identify each order uniquely over all sites and the generated invoice ID is stored in addition in the order table. The invoice ID can also be formatted before being added to the e-mails or the PDFs by using the ordernumber marco:

use \Aimeos\MShop\Order\Item\Standard as Order;

Order::method( 'ordernumber', function( \Aimeos\MShop\Order\Item\Iface $order ) {
    return 'RE-' . date( 'Y' ) . '-' . $order->getInvoiceNumber();
} );

Optimized performance

Job controllers often iterate over a large result set and using the limit and offset values in slice() of the search filter cause long response times until the database found the requested slice. This can take several seconds if the whole result set is more than 100k rows.

For optimal performance, Aimeos offers a cursor based iterate() method in each manager now:

$manager = \Aimeos\MShop::create( $this->context(), 'product' );
$cursor = $manager->cursor( $manager->filter()->add( 'product.instock', '==', 1 ) );

while( $items = $manager->iterate( $cursor, ['price'] ) ) {
    // process items
}

The new iterate() method is most useful if you need to process a large result set completely.

Furthermore, the column order of all indexes in the Aimeos tables have been optimized to get the best performance for the most often used queries. Especially, MySQL uses more parts of the index now because it will use indexed columns in a combined index only as long as there’s no LIKE condition involved.

SEO and 404 improvements

To get the best results in Google, the schema.org markup in the list and detail views has been improved. It’s telling the search engine what’s the name, image, price and description of the product and contains now additional markup for the Google merchant listings. Furthermore, the breadcrumbs from the catalog stage component are now also machine readable for Google.

Before 2022.10, pages with no content or with invalid category/product IDs returned a page without content but no 404 error. This led to many pages without useful content being index by search engines. Now, all category list, product detail and CMS pages which are not available (any more) return a “404 not found” error.

The second stable release in 2022 contains new features and some changes/improvements for developers to keep an eye on. This version focuses on improvements for editors and on minimizing code developers have to write when creating new features in Aimeos. The most important changes are:

• Bulk editing in admin backend
• Customizable theme colors in backend
• Uses Bootstrap icons instead of Fontawesome
• No more need for factories
• Scales images in media manager
• More fractional quantity support
• Improved debugging

Bulk editing

One of the features that can simplify life of editors a lot is editing the values of several items at once. The Aimeos admin interface it’s now possible to do exactly that, not only for single values like the status, but also for multiple values in parallel with one bulk edit request.

For all panels, at least the basic item values can be changed as long as they must be not unique. You can add your own bulk edit options by extending the list template of the panel and add the additional code to subparts or decorators if required.

Customizable theme colors

Aimeos uses CSS variables to define colors and several other important values which are used at several places in the CSS files. This allows you to overwrite these values in your custom CSS file to adapt the frontend design to your needs or to the corporate identity.

In Aimeos 2022.07, you can change those variables not only globally but also per site and theme if you have several themes installed. Thus, each customer/company can select the theme and the appropriate colors themselves for their needs which makes Aimeos a perfect fit for building ecommerce SaaS solutions.

New Bootstrap icons

Up to now, Aimeos have used Fontawesome for all icons in frontend and backend. As new icons in Fontawesome are most often available only in their proprietary icon packages, there was time for choosing a new icon set. In the shop frontend, Fontawesome icons have been replaced in the 2022.04 release and now they are also gone in the admin backend.

Instead, Aimeos is using the Bootstrap icons now, giving the backend a cleaner, more lightweight look and feel that supports the colored theme available since 2021.

Removed factories

Each manager, controller and client required its own factory for creating a new object of that type. This lead to a lot of boilerplate code because the factories had mainly the same code and were just different in the used configuration options and the names of the classes. Beginning with the 2022.07 release, implementing a manager or controller for a new data domain or job as well as clients for the frontend or backend doesn’t require a supporting factory any more.

All objects are now created by the central factories only that have been available for a long time:

$manager = \Aimeos\MShop::create( $context, 'product' );
$cntl = \Aimeos\Controller\Frontend::create( $context, 'catalog' );
$cntl = \Aimeos\Controller\Jobs::create( $context, $aimeos, 'media/scale' );
$client = \Aimeos\Client\Html::create( $context, 'catalog/detail' );
$admin = \Aimeos\Admin\JQAdm::create( $context, 'product' );

Developer experience

We strive for the best developer experience possible, so working with Aimeos should be as easy as possible. In that light, there are a couple of improvements available in this release.

Instead of using the common media contoller to work with image file, the media manager is now able to do that directly by its new scale() method. It offers the same features as the controller which is going to be cleansed next year.

Ordering fractional product quantities is supported since 2020.04 but now, you can also use fractional quantities for multi-level pricing (also known as block pricing). This gives you fine-grained control over pricing of products that can be bought in quantities of less than one or non-integer quantities.

For debugging purpose, all non-item objects where decorators can be added support a classes() method since this version. Thus, you can easily find out, which class has been used for the inner object and which decorators has been wrapped around, so identifying possible issues is now easier then before.

The first stable release of the Aimeos e-commerce framework in 2022 contains a lot of exciting new features and changes compared to the last LTS version. Improving the developer experience further was one of the most important goals for this release besides more performance. All improvements are available for both, Laravel and TYPO3 and include:

• Laravel 9 LTS support
• Integrated distribution based on Laravel 9
• New Aimeos headless distribution built on Laravel 9
• Radically simplified HTML client code base
• Top scores of 100% for Google Lighthouse
• Bootstrap 5 w/o jQuery
• Upscheme migrations
• Higher performance

Laravel 9

Aimeos is the first full-featured e-commerce framework supporting the new Laravel 9 release with long term support (LTS) since beginning of April 2022. The biggest changes necessary for moving to the new Laravel release have been the migration from Swiftmailer to the Symfony mailer package and to FlySystem v3 for file access.

Together with the Aimeos Laravel 2022.04 package which can be added to every existing Laravel 9 installation, the integrated Aimeos distribution is now also based on Laravel 9 LTS. The distribution includes shop and CMS features and you can create a ready to use online shop. Simply execute this on the command line if PHP and the composer package manager are installed:

php composer create-project aimeos/aimeos myshop

In addition, there’s now a Laravel 9 based Aimeos headleass distribution available too. This distribution is especially suited for building your own progressive web application based on ReactJS, VueJS or any other JS frontend framework. It includes the admin backend and the world-class Aimeos JSON REST API but not the traditional HTML frontend. Also, it comes with the pre-configured JSON web token (JWT) package for Laravel installed for authenticating frontend users.

Developer experience

We’ve put a lot of effort into improving the experience for developers, especially the need to write less boilerplate code when implementing own HTML clients. Thus, the necessary code for adding a new HTML component in the frontend is now reduced to the bare minimum. You only need to write the code you really need now and additional methods are not required any more because there are default implementations available for them.

Additionally, the directory structure has been simplified as much as possible. Methods have been shortend and the most important ones only consists of a single word now. A few examples of renamed methods are:

• getContext() -> context()
• getBody() -> body()
• addData() -> data()
• …

For a full list of breaking changes compared to the 2021.10 LTS version, please have a look into the Aimeos changelog in the documentation.

Google Lighthouse scores

Aimeos already achieved top scores for desktops in the past but for mobile devices, the performance score reached a maximum value of 70. Several changes have increased the score to almost 100 now.

The most important change was to split up the three main Aimeos CSS and JS files into one CSS/JS file per component. Now, all CSS rules and Javascript code that is used solely by e.g. the catalog detail component has been moved the their own catalog-detail.css and catalog-detail.js file. They are only sent to the browser if the catalog detail component is used at the requested page. Therefore, the browser doesn’t need to fetch and parse unused CSS/JS code any more which can shorten page loads drastically especially on slow devices/networks.

Furthermore, the used Slick slider contains a lot of JS code which is executed after the document is fully loaded. This increases the “time to interactive” until the users can interact with the page but it’s a crucial value for Google Lighthouse and heavily affects the score. Now, Aimeos uses SwiffySlider, a slider based on CSS animations with only very little JS code. It’s feature-rich, supports touch out of the box and has very little negative effect on performance.

Bootstrap / jQuery

Bootstrap 5 has been used in the backend since 2021.04 and now, the default frontend theme has switched to Bootstrap 5 too. This allowed us to dump the jQuery library in favor of vanilla Javascript but that turned out to be much more code than before. Here’s a code example for jQuery and vanilly JS:

// jQuery
$('.class')

// vanilla JS
document.querySelectorAll('.class')

Vanilly JS is rather inconvenient compared to the terse code you can write with jQuery. To get short code without the bloat of jQuery, we now use the Cash DOM library as instead. It offers the same syntax as jQuery for the “$” function and the collection methods but doesn’t contain the compatibility code for old browsers and uses native browser functionality instead. It also requried to use the new JS fetch API offered natively by modern browsers instead of the jQuery get()/post() methods.

Upscheme migrations

Since 2022.01, Aimeos uses Upscheme for migrating the database schema and the data itself. Compared to using Doctrine DBAL directly, this reduced the required lines of code drastically up to 80% and creating/updating a table now looks like:

$this->db( 'db-message' )->table( 'message', function( Table $t ) {
        $t->id();
        $t->type();
        $t->string( 'label' );
        $t->bool( 'status' );
        $t->meta();
} );

All setup tasks are now located in the setup directory of the Aimeos core and the Aimeos extensions. There’s already an Upscheme article available which explains how to implement setup tasks in Aimeos 2022.x and later.

Performance

To increase performance of Aimeos further, the underlying data structure has been modified. Before, products has been referenced in the mshop_catalog_list table by categories and in the mshop_supplier_list table by suppliers. This required fetching categories and suppliers for products in two separate queries and especially for document-oriented storages like ElasticSearch, it enforced updating the documents two times.

Now, categories and suppliers are attached to products instead of the other way round, so only one additional query per domain is needed to fetch that data for the frontend. It’s now perfectly in line with document-oriented storages can reduce indexing time drastically.

Fast forward a quarter of a century, and in 2019 the revenue stood at a staggering 3.4 trillion dollars. It is projected to almost double and touch $6.5 trillion by 2023.

 The reason for this growth is that online shopping is now commonplace and has really taken off due to convenience, coupled with highly secure payment options.

 At the same time, the evolution and maturity of HTML 5 have meant high-quality landing pages that are visually compelling. Fast internet availability with most places in the world receiving at least megabit data connection has meant the pages can present the products more believably with high-res images.  

The revolution in online commerce has meant that a fast-moving ecosystem has emerged. It is driven by a plethora of new technology that makes life easier for the owner.

Let us discuss some of the latest trends that would help you understand the e-commerce landscape.

New and Emerging Trends in Ecommerce

1.      Small is beautiful

The upward trajectory of e-commerce sales is unstoppable. But that does not mean it is only being served up by Amazon, Rakuten, and Flipkart alone.

Small businesses have flourished. In 2017 it was estimated that there are 500,000 small e-commerce businesses in the US alone. These had a turnover of less than a million dollars and offered niche products such as flowers and specialty items such as dark chocolates and truffles.

Going forward, most small brick and mortar stores would be adding an online arm for boosting revenue. What has facilitated this is the ease with which an online e-store can be set up with the help of such popular ecommerce platforms, like Shopify and Wix.

2.      More use of augmented reality

Anecdotal evidence has shown that it is standardized products from graphics cards to cell phones that are most often purchased through online shopping. The buyer has already seen it in real life and is comfortable buying it online since they are familiar with the product.

This has meant a broad category of goods, especially clothes are not much favored by online shoppers. The use of augmented and virtual reality will soon make this discrimination a thing of the past.

With whole-body scans, you could upload an avatar into a virtual dressing room and try on as many dresses as you want without waiting for your turn. Levi’s and Tommy Hilfiger have incorporated a VR shopping platform known as Obsess to introduce a new paradigm to online shopping. 

3.      E-commerce through voice search

Google Assistant and Apple Siri are becoming significant elements of e-commerce. Voice shopping is used by 11% of users in the US.

As buyers become more accustomed to using voice search for more than a playlist and weather, they would purchase through conversations.

This is a critical technology that cannot be ignored by e-commerce store owners. Though the backend evolution of software to match voice shopping still is not widely available, it is expected to change in the next two years as a large number of plugins become available.

Amazon has already leveraged Alexa for this purpose. It is going to be the next big thing in e-commerce.

4.      Green is great

Carbon footprint is no longer a buzzword. Either a business takes it seriously or perishes. With green campaigns on the rise and consumers turning eco-friendly, e-commerce also needs to wake up and smell the coffee.

This would mean creating business models that are as close to carbon neutral as possible.

Ecommerce is under increasing scrutiny due to its usage of packaging material that is not biodegradable. Bubble wrappers made of plastic are not approved by post-millennials who march to the tune of Greta Thunberg.

Also, employing hosting providers who use renewable sources of power and have green certification are bound to make a difference and create positivity among buyers.

5.      Mobile shopping on the rise

Statista has predicted that the rise of mobile e-commerce will continue and touch 70% by the end of next year.

To take advantage of this change, every e-commerce site needs to have a dedicated app that is well designed and can work seamlessly with their website.

It is not very difficult to create such an app because it acts as an extension to the existing website and does not need far-reaching backend coding.

What it does need is downloads, and that means persuading the customer to spare a few pixels of valuable smart device screen area.

This can be driven by app-only discounts coupled with classic app store optimization techniques.

6.      Emergence of social commerce

Social media has brought a sea change to the way we know, think, and act. It was only a matter of time before it began to impact our buying behavior.

That is now present, though mostly on Facebook and Instagram for the past year.

25% of e-commerce store owners are selling through Facebook. Instagram Checkout is something similar that allows you to buy without ever leaving the app.

Why is this important? It is because people check social media several times a day, and if you want to push a product, it is ideal to use a social media platform.

Even TikTok, the new kid on the block, is allowing users to add links to e-commerce sites.

7.      Google Shopping is the new goliath

Google Shopping is not an online marketplace, but it is the 800 pound gorilla in the room, one that even a giant like Amazon cannot ignore.

While Google has till now stayed out of retail, it is the most quintessential technology that online shopping uses bar none.

You could avoid Shopify and use Magento, replace the marketing campaign on Facebook with Instagram, but Google is an unchanging constant.

Google Shopping is a market price comparison tool that shows up in every search you make. Formerly known as Froogle (Frugal Google), it has been around since 2002. But it is only recently that it has become a colossal influencer that you can’t ignore.

8.      Finapps make an impact

Mobile payment apps are popular in Asia, where credit cards are yet to make an impact. Tencent and WeChat showed the way, and it was quickly copied by Square, Google Pay, and Apple Pay.

These speed up online commerce by allowing you to add a payment option on the checkout page. They are, in fact, safer than credit or prepaid cards and add layers of security that does not depend on SMS for verification.

Moreover, they allow QR code scanning as well as shopping from inside the app. they are particularly useful for allowing customers to earn loyalty points and pay safely from their home.

For phones that use NFC, they also add this functionality, thus making it necessary to physically carry a credit card.

9.      AI for search

The use of AI for product recommendations is growing. The understanding of buyer behavior from browsing habits and crunching the click habits is going to be a gamechanger.

It is not a simple suggestion for the latest CPU that you get when you buy a motherboard. It is a predictive behavior analysis that is making e-commerce shopping a whole new experience.

The recommendation engines no longer only show five more types of dress style because you hovered on one. They show you the colors that you like.

It is this type of advanced assistance that gives AI the capability to enhance the shopping experience.

10.  Chatbots that are informative

Have you noted how chatbots are becoming more human? They are almost as good as a human sales assistant in a physical store. You could say that they are also less annoying because you could shut them down at any time without fear of offending.

Some studies have shown that 60% of shoppers like to have a chatbot reply to basic queries.

Improved customer engagement is a key sales driver, and they work 24×7 without feeling exhausted. What’s more, the queries can be directly linked to analytics, and thus better offers can be presented suited to customer expectations.

Last Words

Ecommerce trends are evolving so rapidly that it is hard to keep pace with them. That is why we have presented the ten most significant for the current year. Of course, you may not need to adopt all of them at the same time since quite a few are technologies that are yet to mature. But it is a clear indication of the road ahead and what it will look like.

GraphQL is hot these days! More and more GraphQL APIs appear and especially in the Javascript / NodeJS scene, GraphQL is extremely popular. As progressive web applications using GraphQL are also on the rise (not only in the e-commerce area), we compare how GraphQL and the JSON REST API standard fits for e-commerce applications based on our experience in these areas:

• Ease of implementation and use
• Performance and scalability
• Reading and writing data

GraphQL

The GraphQL specification was invented by Facebook because they need to retrieve data efficiently by web clients to render their frontend. Facebook accounts and their relationships to other accounts are a graph they need to query, hence the name “Graph Query Language”. The clients should be able to do complex queries while minimizing the data in the response to the really required properties only.

Advantages

One API for all client requirements

There’s only one API endpoint that can handle all client requests. Internally, the requests for different resources may be routed to different APIs so a GraphQL server can act as a director for different services. For the clients this may be easier to work with.

Efficient requests including related resources

With one request, you can not only retrieve the data of the requested resource. Instead, you can also fetch all related resources that are referenced by the requested resource entries. This reduces the number of required requests to retrieve all data to exactly one.

Retrieve only the data you really need

For each resource and related resource, only the required properties can be retrieved. Thus, the amount of data transfered over the network is reduced to the absolute minium that is required by the client.

Writing several (related) resources at once is possible

Creating and updating resources and related resources can be done in only one request. This means, saving data isn’t limited by the network but only by the server processing the requests.

Exact schema definition is provided by the server

A GraphQL API requires a schema that exactly specifies the resources, its properties and types as well as what queries can consist of. This enables built-in introspection and schema validation on the client and server.

type Product {
  id: ID
  label: String
  status: Boolean
}

Well defined query language

The specification tells you exactly how queries look like, independent of the concrete GraphQL API implementation:

{
  product(code: '1000.001') {
    label
    attribute(type: 'variant') {
      id
      name
  }
}

Client side libraries for working with the API available

There are Javascript libraries available for working with GraphQL APIs easily, the most widely used one is Apollo. Contrary to the simple JSON:API this is absolutely necessary because its hard to implement a GraphQL API by hand.

Disadvantages

No caching by CDNs or proxies possible

All requests are sent as POST request in the body of the request. This makes it impossible for intermediate caches to store those requests and return the response immediately. Thus, scaling a GraphQL API is only possible by adding more servers.

Optimizing queries can be hard because they are not fixed

Each client can send arbitrary queries to the GraphQL server. They can be different in the fields requested or related resources as well as the used filters so it’s difficult to create indexes for the database tables.

Clients can build deep and complex queries overloading the server

As servers don’t implement a fixed list of queries, malicious clients can build deeply nested queries that doesn’t use the indexes of the database. This can lead to a denial of service attack easily.

Client and server are thighly coupled how they work together

Whenever an item in the backend is refactored or its properties renamed, all clients consuming the GraphQL API has to be updated. To avoid that you need to keep the original data structure forever and only adding new items and properties but that will bloat your backend code of the time.

Application state and what’s possible next must be programmed into the client

Clients can use all kinds of queries to fetch data from the server but they don’t get any information what they should do with that data. Developers must hard-code the next steps in the clients, e.g. how to fetch the data for the next list page or how to add the product to the basket.

Query language adds more complexity

The GraphQL query language is more complex than using a simple URL with some parameters. Instead, you have to write a complex query even if you only want to retrieve all products with their names, e.g.

curl -X POST -H 'Content-Type: application/json'
    -d '{ "query": "{ products { name } }" }'
    http://localhost/graphql

Client side caching necessary which may introduce additional points of failure

Because caching by CDNs and proxies is impossible, the GraphQL server only has limited resources and network latency is bad for the user experience, you have to implement caching in the client. This can add another source of problems to your software stack that’s hard to debug.

‍JSON:API

The JSON:API standard was invented by Ember.js, one of the first major Javascript frameworks. It’s main goal is to reduce the amount of client code required for using a server API that communicates in a well defined way. Implementation on the client and server side should be easy and use existing best practices.

Advantages

Efficient requests which can include related resources

Usually, one one request is needed to fetch all required data from the server because you can use the “include=text,price,media” parameter to fetch all listed resources too.

Fetch only required data

You can pass the “fields” parameter to fetch only the properties you need from the server just like you can using GraphQL. This also works for related resources:

http://localhost/jsonapi/product?fields[product]=id,label&fields[text]=langid,content

Excellent caching by CDNs, proxies and browsers

REST APIs perfectly fit to the current internet infrastructure. The browser and intermediate servers automatically cache responses so services offered via a JSON:API can scale indefinitely for read heavy applications.

Client and server are decoupled for independent evolution

Request don’t map directly to the entries in the (NoSQL) database, so you can change the backend and data structures while still maintaining compatibility to clients implementing a previous version of the API.

Application state can be managed by the server

The JSON:API standard includes a “links” section which contains links for the next possible actions like moving forward to the next page or for adding a product to the basket. Thus, the client doesn’t have to know how to build them on its own.

"links": {
    "self": "http:\/\/localhost\/jsonapi\/product\/13",
    "next": "http:\/\/localhost\/jsonapi\/product\/21",
    "basket\/product": "http:\/\/localhost\/jsonapi\/basket\/default\/product"
}

Queries can be optimized for the required use cases

In contrast to GraphQL, you have to think about the use cases for your JSON:API upfront because clients can’t ask for something there’s no resource endpoint for. In terms of optimization possibilities that’s a huge advantage because you know what kind of queries you can expect.

Interacting with the API is plain simple

There’s no query language involved for simple requests and returning the list of products with their name is only a matter for using:

curl http://localhost/jsonapi/product?fields=label

Disadvantages

Only single resource (database record) can be updated at once

Write heavy applications where also related resources must be updated (think about e.g. an administration interface) are not suited well for a REST API. You can only update one resource per request which can require multiple requests necessary if you want to save data.

No specification of the query language so every implementation has it’s own

There’s a “filter=…” parameter defined in the JSON:API standard but not the query language behind due to different requirements. This leads to custom implementations for each API but client developers may need to handle several query languages in one client.

No schema returned by default, has to be documented elsewhere

For the returned items and properties, there doesn’t exist a common schema description including the data types. Developers need to know what the server will return.

Schema validation must be done yourself

The APIs implementing the JSON:API standard are not self descriptive and you need to manually verify that the request and response matches the documented properties and types.

Conclusion

There are some good reasons why to use GraphQL but it’s not a replacement for all JSON REST API as some are stating with “GraphQL is taking over APIs”.

The best use case for GraphQL according to our observations is for internal APIs where the tight coupling between client and server isn’t a big problem. They can also act perfectly as a single endpoint for clients. Futhermore, you should think about access control to the GraphQL API because it’s inherently prone to denial of service attacks. The lack of scalability is a good reason to hide it from the public too.

APIs based on the JSON:API standard are better suited “for the wild” than GraphQL according to the current state. They enable clients and servers to evolve independently and can also reduce code in the clients. When leveraging CDNs and set cache timeouts correctly, JSON:APIs can scale infinitely. Only for applications with many writes to several resources at once they are not suited well.

Every online shop needs to send e-mails and so the Aimeos e-commerce framework does. They are still the best option to confirm the order and tell customers about changes in the delivery and payment status. Nevertheless, even nowadays, creating appealing e-mails for different devices is hard stuff! Software seem to be from year 2000 when comparing support for HTML5 and CSS in e-mail clients.

Most of the time, support is limited for security reasons which is a good thing because compared to web sites you have to visit actively, everyone can send you e-mails. But often, simple features aren’t implemented since more than ten years or are buggy and therefore unusable. Outlook falls into the later category and it seems that Microsoft wants to punish us forever!

Response e-mail frameworks

Thus, the only way to get e-mails that look similar (not equal) in most clients is using tables and a limited set of inline CSS. Because it’s hard to write the code that is most compatible by hand, there are two frameworks that makes life easier: MJML and Foundation for Emails. Both offer a simple syntax and generate the HTML/CSS code for you.

The biggest difference between both is that Foundation is more complex than MJML. Using Foundation, you have to wrangle with several libraries and build tools at the same time while with MJML, you can generate the output with a tool of your choice (NPM, Visual Studio Code plugin or even using a web service). The ease of use and the choice of the build chain were the crucial factors for using MJML in Aimeos.

MJML structure

MJML has a simple XML-based syntax and uses its own tags for describing the content. The custom tags will get translated into HTML and inline CSS while generating the output. A basic MJML document looks like:

<mjml>
  <mj-head>
    ...
  </mj-head>
  <mj-body>
    ...
  </mj-body>
</mjml>

This corresponds to the standard HTML structure. Building a reponsive grid with MJML is rather simple: You need the “<mj-section>” and “<mj-column>” tags and and create any number of columns simply by using “<mj-column>” multiple times. This would create a responsive grid with three columns:

<mjml>
  <mj-body>
    <mj-section>
      <mj-column>column one</mj-column>
      <mj-column>​column two</mj-column>
      <mj-column>column three</mj-column>
    </mj-section>
  </mj-body>
</mjml>

Note: You can’t add any additional tags between the “<mj-section>” and “<mj-column>” tags! Furthermore, most of the MJML tags are only allowed within the “<mj-column>” tags.

Basic MJML tags

The “<mj-head>” can contain two tags often used: “<mj-font>” to use a specific font and “<mj-style>” for CSS styles that will be part of the e-mail. If “<mj-style>” contains the “inline” attribute, the styles will be copied to the style attributes of the HTML tags directly instead of referencing them from the head section. This is especially useful for the Gmail App, which discards “<style>” tags in e-mails depdending on the account type.

<mjml>
  <mj-head>
    <mj-font name="Noto" href="https://fonts.googleapis.com/css?family=Noto Sans" />
    <mj-style inline="inline">
      .logo img { max-width: 300px; margin: auto }
      .blue-text h1 { color: #103050; text-align: center }
      .btn td, .btn a { color: #fff; background-color: #ba9a5a !important; }
    </mj-style>
  </mj-head>
  <mj-body>
    <mj-section>
      <mj-column>
        <mj-image css-class="logo" src="https://aimeos.org/fileadmin/logos/aimeos.png" />
        <mj-text css-class="blue-text" font-family="Noto, Arial">
          <h1>Hello World!</h1>
        </mj-text>
        <mj-button css-class="btn" href="https://example.com/">Click me</mj-button>
      </mj-column>
    </mj-section>
  </mj-body>
</mjml>

Referenced images using “<mj-image>” are responsive by default which means their width automatically adapts to the available size of the container. E-mail clients often don’t show images by default for security reasons. To circumvent that to a certain degree, you can add the images to the e-mail as attachments referenced by the content ID (CID) technique or by using base64 encoded inline images.

CSS classes are assigned to the MJML tags with the “css-class” attriubutes. If you have a look at the “<mj-style>” section, the selector for the CSS class isn’t the same as the CSS class itself, e.g. “.logo img” is used for css-class=”logo”. This is due to the generated HTML by MJML, which is something like that for the “<mj-image>” tag:

<table border="0" cellpadding="0" cellspacing="0" role="presentation"
  style="border-collapse:collapse;border-spacing:0px;">
  <tbody>
    <tr>
      <td style="width:550px;">
        <img height="auto"
          src="https://aimeos.org/fileadmin/logos/logo-aimeos-blue.png"
          style="max-width: 300px; margin: auto; border: 0; display: block;
            outline: none; text-decoration: none; height: auto;
            width: 100%;" width="550">
      </td>
    </tr>
  </tbody>
</table>

Also, MJML adds some default inline styles to almost all generated HTML. If your application application supports themes like Aimeos does, this is a bit cumbersome because you have to enforce some styles with the “!important” modifier.

Using tables in MJML

For tabular data like the products bought with image, name, quantity and price for each line, HTML tables are still the best option. MJML offers the “<mj-table>” tag to add an HTML table. Within the “<mj-table>” tags, you must use the standard HTML tags like “<tr>”, “<th>” and “<td>”:

<mjml>
  <mj-head>
    <mj-style>
      .order img { width: 100%; max-width: 100px; height: auto }
    </mj-style>
  </mj-head>
  <mj-body>
    <mj-section>
      <mj-column>
        <mj-table css-class="order">
          <tr>
            <th></th>
            <th>Name</th>
            <th>Qty</th>
            <th>Price</th>
          </tr>
          <tr>
            <td><img width="100" src="https://demo.aimeos.org/media/1.jpg"/></td>
            <td>Demo product</td>
            <td>1</td>
            <td>100,00 €</td>
          </tr>
        </mj-table>
      </mj-column>
    </mj-section>
  </mj-body>
</mjml>

Note: Within the “<mj-table>” tags, you are totally on your own! No MJML tags are parsed within the table and you have to care about the responsiveness of images yourself for example. Some e-mail clients like Outlook doesn’t use width styles for images and for those, you should add a “width” attribute to the “img” tag directly.

MJML to HTML

As no e-mail client can parse MJML directly, you have to generate the HTML code before sending the e-mails to the recipients. There are several ways where you can choose from depending on your environment and preferences:

• Pasting your MJML code into the online form: https://mjml.io/try-it-live
• Sending the code to the MJML API for processing: https://mjml.io/api
• Using NPM in your build chain: https://mjml.io/documentation/#installation
• Download the MJML extension for your editor: https://mjml.io/documentation/#tooling
• Install MJML for Visual Studio Code: https://github.com/attilabuti/vscode-mjml

All of those will create an HTML document which you can add to your e-mails as HTML part. You can use placeholders or even PHP code within the MJML tags because it won’t get touched. That way, you can process the generated output and insert personalization or add dynamic content. You can have a look at the Aimeos MJML templates and the generated code.

More about Aimeos