Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Insight into the Shopware 6 core architecture

Insight into the Shopware 6 core architecture

With Shopware 6, the architecture was rethought from scratch and adapted to today's eCommerce.

In this session, Jan Bücker and Jonas Elfering will give you a deeper insight into the PHP-side architecture and functionality. All important and interesting sections from Context to the Data Abstraction Layer are introduced to you step by step, so that you are prepared to get started with Shopware 6.

Jan Bücker

May 23, 2019
Tweet

Other Decks in Technology

Transcript

  1. Jan Bücker Developer Core ➜ 4 years at shopware AG

    ➜ Born ‘89 ➜ Say hi on twitter @janbuecker ➜ I music! ❤
  2. Attention! This talk is based on v6.0.0+dp1 and implementations may

    change with upcoming releases. already changed
  3. Agenda • Project structure • API • Context • Translations

    • Data Abstraction Layer • Cart • Business Events
  4. Project template Blueprint for projects Tailored for specific needs e.g.

    • Production (high performance) • Development (debugging) • Cloud hosting specific customization (AWS, GCP, Azure) • Overwrite default config values Project template • Platform • Shopware 6
  5. Platform Mono repository for Shopware 6 modules • One repository

    containing all modules • Easy to make changes across all modules to maintain stability • Split into Many-Repositories • Contributions go here Project template • Platform • Shopware 6 https://github.com/shopware/platform
  6. Many Repositories Composable bundles, that are structured by domain •

    Core • Administration • Storefront • Docs These are read-only. Do not contribute to them. Project template • Platform • Shopware 6
  7. Shopware 6 The Product Project template + • Core •

    Administration • Storefront • Plugins Project template • Platform • Shopware 6
  8. Technical requirements • Web server running php • PHP >=

    7.2 • MySQL >= 5.7 (MariaDB >= 10.3) ◦ High group_concat_max_len Optional • Node.js >= 8.10 • NPM >= 6.5
  9. Admin API • Manage your Shop • Used by the

    Administration • CRUD operations for every entity • Action routes for everything else
  10. Admin API • Stateless • Auth via OAuth (JWT) •

    Dynamic OpenAPI 3 schema including all entities • Supports JSON:API ◦ Deduplication built-in ◦ Self-discovery ◦ Implementations for various languages
  11. Sync API or Admin Batch API • Single endpoint in

    Admin API • Multiple actions in one request ◦ upsert ◦ delete • Probably faster with large data sets (in the future)
  12. Sales Channel API • Storefront functionality ◦ Sell products via

    API ◦ Perform checkout ◦ Manage your account • Authentication with pre-shared key • Dynamic OpenAPI 3 schema for all available routes
  13. Context Crucial information of a request • Immutable object •

    Built from the request • Runtime information
  14. • 3 levels of inheritance priority ◦ current language ◦

    root language ◦ system language Context Language chain for partial translations
  15. • 3 levels of inheritance priority ◦ current language ◦

    root language ◦ de-DE Context Language chain for partial translations
  16. • 3 levels of inheritance priority ◦ current language ◦

    en-GB ◦ de-DE Context Language chain for partial translations
  17. • 3 levels of inheritance priority ◦ en-US ◦ en-GB

    ◦ de-DE Context Language chain for partial translations
  18. Content Translations • Built into the Data Abstraction Layer •

    Translated fields can be managed in all languages • Inheritance with partial translations
  19. Why? Reasons not to use Doctrine ORM • Difficult to

    optimize • Not suitable for core concepts • Entities not extendable for plugins • Not possible to enforce patterns
  20. Data Abstraction Layer • tag your entity with shopware.entity.definition •

    add a DB migration optional • add a EntityClass • add a CollectionClass if necessary • add a translation definition Define your own Entities
  21. Indexer • Denormalization for improved read performance • Denormalized data

    needs synchronisation ◦ Build the whole index ◦ Update the index for updated entities only Synchronizing denormalized data
  22. Migrations • Blue/Green compatible • 2-Phase Migrations ◦ update ◦

    updateDestructive • usable for Plugins as well Updating the DB schema
  23. Migrations • Must be compatible with old and new application

    ◦ No breaking changes • Application rollback without another DB schema migration 1. Phase: update
  24. Migrations • Contains the breaking changes • Application rollback not

    possible • Last possible rollback point -> last destructive Migration 2. Phase: updateDestructive
  25. Data Abstraction Layer Common obstacles • IDs are binary UUIDs

    • Objects for reading • Arrays for writing • Translated properties must be nullable
  26. Actions for Business Events Add actions for events: • Send

    an email • Call an API • Send a Slack message
  27. Further topics • Filesystem • Custom Fields • Tooling •

    Versioning • Message Queue • Custom Rule Builder rules